mirror of https://github.com/mailscope/kumomta.git synced 2026-10-26 16:26:14 +00:00

T

Wez Furlong 41f1216934 fix potential deadlock w/ spool manager & incorrect ready queue bounce logic

While spool enumeration is ongoing, we'd keep an exclusive lock
on the spool manager.

If we'd subsequently need to remove a message from spool, we'd
attempt to obtain a lock on the spool manager to be able to reference
the spool.

In the best case, the removal logic would be triggered from a separate
task, and would eventually succeed once enumeration completes.

However, if the calling context holds a lock on a schedule queue
then we'd have potential to deadlock, especially in the case where
we are processing an admin bounce request via the HTTP API which
needs to iterate all queues, lock them and then initial the bounces
and associated removal of the messages from the spool.  Holding a
scheduled queue lock would prevent forward progress in the spool
enumeration logic which also needs to lock that queue to insert
newly enumerated messages.

In many cases this issue would not be noticed until attempting
to shutdown the server where it would manifest as waiting forever
to shut down.

This commit removes the possibility of deadlock by adjusting
the composition of the SpoolManager.  Now, instead of needing
to lock the entire spool manager, the locks are scoped to the map
that manages the named spools; the critical section for those is
now just long enough to obtain a handle.

While examining the flow of this stuff I realized that the admin bounce
processing was overly aggressive and would bounce all the messages in
the ready queues associated with the matching scheduled queue.  That's
incorrect as the ready queues are potentially shared with other
scheduled queues can feed into those same ready queues.

I adjusted the logic for those so that we process the admin bounce
entry as part of dispatching the ready queue instead of trying to
bulk fail the ready queue.

2023-06-21 12:27:59 -07:00