From: "Zqiang" <qiang.zhang@linux.dev>
To: "Sunho Park" <shpark061104@gmail.com>, rcu@vger.kernel.org
Cc: paulmck@kernel.org, linux-kernel@vger.kernel.org,
"Sunho Park" <shpark061104@gmail.com>,
syzbot+d4faf7db59e11f6fd1ab@syzkaller.appspotmail.com
Subject: Re: [BUG] srcu: false-positive WARN in cleanup_srcu_struct() after 78a38cbf6f20
Date: Tue, 25 Aug 2026 12:33:03 +0000 [thread overview]
Message-ID: <494f3e0cdb3692bf13690f4cddd3b40098b51627@linux.dev> (raw)
In-Reply-To: <20260824105625.3725157-1-shpark061104@gmail.com>
>
> The main crash report [1] which is tested on non-merged commit 6b8c8af514d7
> is caused by the single-condition WARN_ON(timer_delete_sync(&sdp->delay_work))
> in cleanup_srcu_struct(&kvm->irq_srcu). As discussed in [2], it is a false
> positive because irq_srcu does not use call_srcu().
>
> However, the merged WARN_ON(timer_delete_sync(&sdp->delay_work) &&
> rcu_segcblist_n_cbs(&sdp->srcu_cblist)) is also triggered in
> cleanup_srcu_struct(&kvm->srcu) which is called after srcu_barrier() properly.
> Although my syz test command [3] failed to reproduce, it was reproducible
> in my QEMU environment built with the .config of the report.
>
> I found out that the return value of rcu_segcblist_n_cbs can be nonzero
> even after srcu_barrier() because of the srcu_barrier_cb() that srcu_barrier()
> inserts at the end of the queue. The length of cblist is decreased after
> srcu_invoke_callbacks() finishes invoking all callbacks in a batch. But
> srcu_barrier() may return when all the srcu_barrier_cb() are called, bringing
> the counter to zero, even if srcu_invoke_callbacks() has not yet decremented
> the length. So checking cblist length before flush_work() is inaccurate.
If srcu_barrier() be invoke before srcu_cleanup(), and after srcu_barrier()
completion, there are no concurrent srcu grace period start again (e.g. call_srcu() calls),
the timer_delete_sync() should return false, the rcu_segcblist_n_cbs()
will not be check.
Or did I miss something?
Thanks
Zqiang
>
> By the comment of srcu_barrier(), it guarantees that all the previously
> registered call_srcu() callbacks are completed. Therefore srcu_barrier()
> did what it said, only the length of cblist was not updated. I think there
> are two options:
>
> 1) Not to check the length of cblist before flush_work()
> 2) Make srcu_barrier() guarantee the length of cblist is adjusted when it returns
>
> [1] https://lore.kernel.org/all/6a78d191.b50370da.49fe0.0042.GAE@google.com/T
> [2] https://lore.kernel.org/rcu/01484cd339ea024dd7c01f02a9781f00e67cb52d@linux.dev/T
> [3] https://lore.kernel.org/all/6a8bc111.91706f20.16b6e3.02cd.GAE@google.com
>
> Reported-by: syzbot+d4faf7db59e11f6fd1ab@syzkaller.appspotmail.com
>
next prev parent reply other threads:[~2026-08-25 12:33 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-24 10:56 Sunho Park
2026-08-25 12:33 ` Zqiang [this message]
2026-08-25 16:50 ` Sunho Park
2026-08-26 13:13 ` Zqiang
2026-08-26 16:03 ` Sunho Park
2026-08-26 23:53 ` Zqiang
2026-08-27 9:11 ` Sunho Park
2026-08-27 11:13 ` Zqiang
2026-08-27 11:35 ` Zqiang
2026-08-27 12:30 ` Sunho Park
2026-08-27 12:40 ` Zqiang
2026-08-27 13:03 ` Sunho Park
2026-08-27 13:40 ` Zqiang
2026-08-27 13:41 ` Zqiang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=494f3e0cdb3692bf13690f4cddd3b40098b51627@linux.dev \
--to=qiang.zhang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=paulmck@kernel.org \
--cc=rcu@vger.kernel.org \
--cc=shpark061104@gmail.com \
--cc=syzbot+d4faf7db59e11f6fd1ab@syzkaller.appspotmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®