[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <27f4ffbe-2342-484d-9924-716a799b265f@paulmck-laptop>
Date: Wed, 19 Feb 2025 05:58:05 -0800
From: "Paul E. McKenney" <paulmck@...nel.org>
To: Joel Fernandes <joelagnelf@...dia.com>
Cc: syzbot <syzbot+ae5b16688c0c675b1a1f@...kaller.appspotmail.com>,
jiangshanlai@...il.com, josh@...htriplett.org,
linux-kernel@...r.kernel.org, mathieu.desnoyers@...icios.com,
rcu@...r.kernel.org, rostedt@...dmis.org,
syzkaller-bugs@...glegroups.com
Subject: Re: [syzbot] [rcu?] WARNING in srcu_invoke_callbacks (2)
On Wed, Feb 19, 2025 at 08:25:38AM -0500, Joel Fernandes wrote:
> On Tue, Feb 18, 2025 at 09:47:27AM -0800, syzbot wrote:
> > Hello,
> >
> > syzbot found the following issue on:
> >
> > HEAD commit: a64dcfb451e2 Linux 6.14-rc2
> > git tree: git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-kernelci
> > console output: https://syzkaller.appspot.com/x/log.txt?x=12398f18580000
> > kernel config: https://syzkaller.appspot.com/x/.config?x=c9c47badcd079906
> > dashboard link: https://syzkaller.appspot.com/bug?extid=ae5b16688c0c675b1a1f
> > compiler: Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > userspace arch: arm64
> >
> > Unfortunately, I don't have any reproducer for this issue yet.
> >
> > Downloadable assets:
> > disk image: https://storage.googleapis.com/syzbot-assets/c0a862fcec77/disk-a64dcfb4.raw.xz
> > vmlinux: https://storage.googleapis.com/syzbot-assets/f03793fc001b/vmlinux-a64dcfb4.xz
> > kernel image: https://storage.googleapis.com/syzbot-assets/ae71c33eae14/Image-a64dcfb4.gz.xz
> >
> > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > Reported-by: syzbot+ae5b16688c0c675b1a1f@...kaller.appspotmail.com
> >
> > ------------[ cut here ]------------
> > WARNING: CPU: 0 PID: 6430 at kernel/rcu/srcutree.c:1798 srcu_invoke_callbacks+0x368/0x3d8
>
> This is weird, happens to be WARN_ON_ONCE(ready_cbs.len); in
> srcu_invoke_callbacks().
Thank you for tracking that down!
> Perhaps, stack corruption or the SRCU cblist's ->seglen got corrupted?
That has been the usual cause. And a double call_srcu() is a common
cause of ->cblist corruption. We have CONFIG_DEBUG_OBJECTS_RCU_HEAD=y
set up for SRCU as well as for RCU, it appears, so perhaps retry with
that should this ever become reproducible?
Thanx, Paul
Powered by blists - more mailing lists