On Wed, Sep 30, 2026 at 05:27:19PM -0700, Sean Christopherson wrote:
> On Fri, Sep 18, 2026, Paul E. McKenney wrote:
> > From: Sunho Park <[email protected]>
> >
> > The WARN_ON() added by commit 78a38cbf6f20 ("srcu: Queue sdp->work
> > when the delay timer is successfully deleted") uses rcu_segcblist_n_cbs()
> > to detect callbacks that srcu_barrier() failed to wait for. However, the
> > ->len counter is decremented only at the end of srcu_invoke_callbacks(),
> > after the invoking loop has finished. Since srcu_barrier() can return
> > right after the barrier callback is invoked, cleanup_srcu_struct() can see
> > a non-zero n_cbs even though the cblist is already physically empty,
> > falsely triggering the WARN_ON() together with a still-pending delay_work
> > timer.
> >
> > This can be triggered as follows, as seen in the syzbot report against
> > kvm_destroy_vm() -> cleanup_srcu_struct(&kvm->srcu):
> >
> > 1. call_srcu(&kvm->srcu, &bus->rcu, __free_bus) starts SRCU grace
> > period GP1.
> >
> > 2. GP1 ends: a delay timer is armed and sdp->work is queued, but
> > sdp->work has not run yet.
> >
> > 3. Another call_srcu(&kvm->srcu, &bus->rcu, __free_bus) call invokes
> > srcu_segcblist_advance(), which moves the GP1 callback to
> > RCU_DONE_TAIL, and starts SRCU grace period GP2.
> >
> > 4. srcu_barrier() is called. It queues its barrier callback after the
> > GP2 callback and waits for srcu_invoke_callbacks() to invoke it.
> >
> > 5. GP2 ends: another delay timer is armed, and the sdp->work queued in
> > step 2 begins to run. Its srcu_invoke_callbacks() call invokes
> > srcu_segcblist_advance() again, moving the GP2 and barrier callbacks
> > to RCU_DONE_TAIL as well, and then invokes all of them. However,
> > rcu_segcblist_add_len(), which updates srcu_cblist's ->len, has not
> > run yet at this point.
> >
> > 6. srcu_barrier() returns once its callback has been invoked, and
> > cleanup_srcu_struct() starts running. It finds the delay timer
> > armed in step 5 still pending and srcu_cblist's ->len still
> > non-zero (because step 5 has not reached rcu_segcblist_add_len()
> > yet), and WARN_ON() fires even though every callback has actually
> > been invoked.
> >
> > Use rcu_segcblist_empty(), which checks the actual head of the cblist,
> > instead of rcu_segcblist_n_cbs(), which checks the racy ->len counter.
> > Callbacks that have genuinely not been invoked yet still leave the list
> > non-empty, so the WARN_ON() still catches callers that skip srcu_barrier()
> > or queue callbacks after it.
> >
> > Link:
> > https://lore.kernel.org/rcu/[email protected]/T/#t
> > Reported-by: [email protected]
> > Closes: https://syzkaller.appspot.com/bug?extid=d4faf7db59e11f6fd1ab
> > Fixes: 78a38cbf6f20 ("srcu: Queue sdp->work when the delay timer is
> > successfully deleted")
> > Suggested-by: Zqiang <[email protected]>
> > Signed-off-by: Sunho Park <[email protected]>
> > Signed-off-by: Paul E. McKenney <[email protected]>
> > ---
>
> Is this going to be grabbed for 7.3? It shows up relatively frequently in
> KVM.
> Not so much that it's truly problematic/alarming, but enough that it
> definitely
> stands out.
>
> Tested-by: Sean Christopherson <[email protected]>
I wasn't thinking in terms of doing so, figuring that the almost-here
merge window would be good enough. But it does seem to apply cleanly.
Any other votes for pushing it into 7.3? If I do so, it must be soon.
Either way, I will of course apply your Tested-by.
Thanx, Paul
