On Tue, Mar 31, 2026 at 01:51:11PM -0700, Paul E. McKenney wrote:
> On Tue, Mar 31, 2026 at 11:17:19AM -0700, Sean Christopherson wrote:
> > +srcu folks
[ . . . ]
> > Unless I'm misunderstanding the bug, "fixing" in this in KVM is papering
> > over an
> > underlying flaw. Essentially, this would be establishing a rule that
> > synchronize_srcu_expedited() can *never* be called while holding a mutex.
> > That's
> > not viable.
>
> First, it is OK to invoke synchronize_srcu_expedited() while holding
> a mutex. Second, the synchronize_srcu_expedited() function's use of
> workqueues is the same as that of synchronize_srcu(), so in an alternate
> universe where it was not OK to invoke synchronize_srcu_expedited() while
> holding a mutex, it would also not be OK to invoke synchronize_srcu()
> while holding that same mutex. Third, it is also OK to acquire that
> same mutex within a workqueue handler. Fourth, SRCU and RCU use their
> own workqueue, which no one else should be using (and that prohibition
> most definitely includes the irqfd workers).
>
> As a result, I do have to ask... When you say "multiple irqfd workers",
> exactly how many such workers are you running?
Just to be clear, I am guessing that you have the workqueues counterpart
to a fork bomb. However, if you are using a small finite number of
workqueue handlers, then we need to make adjustments in SRCU, workqueues,
or maybe SRCU's use of workqueues.
So if my fork-bomb guess is incorrect, please let me know.
Thanx, Paul
> > > 4. The mutex holder never releases the lock -> deadlock
