[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <2c367857-e1a5-4235-94f4-724441e94968@nvidia.com>
Date: Wed, 19 Feb 2025 10:09:06 -0500
From: Joel Fernandes <joelagnelf@...dia.com>
To: paulmck@...nel.org
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 2/19/2025 8:58 AM, Paul E. McKenney wrote:
> 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!
Sure!
>> 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?
Makes sense, will keep an eye out for it!
thanks,
- Joel
Powered by blists - more mailing lists