On Wed, Sep 30, 2026 at 05:57:21PM -0700, Paul E. McKenney wrote:
> 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.
I take it back. Unless there are objections to my pushing this into v7.3
(instead of waiting until the v7.4 merge window), I will push it tomorrow
(Friday October 2), Pacific Time.
> Either way, I will of course apply your Tested-by.
And done!
Thanx, Paul
