Re: [syzbot] [rdma?] WARNING in ib_uverbs_release_dev

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Jun 19, 2024 at 10:16:20PM +0800, Zhu Yanjun wrote:
> 在 2024/6/19 17:15, Leon Romanovsky 写道:
> > On Tue, Jun 18, 2024 at 11:37:18PM -0700, syzbot wrote:
> > > Hello,
> > > 
> > > syzbot found the following issue on:
> > > 
> > > HEAD commit:    2ccbdf43d5e7 Merge tag 'for-linus' of git://git.kernel.org..
> > > git tree:       upstream
> > > console output: https://syzkaller.appspot.com/x/log.txt?x=179e93fe980000
> > > kernel config:  https://syzkaller.appspot.com/x/.config?x=fa0ce06dcc735711
> > > dashboard link: https://syzkaller.appspot.com/bug?extid=19ec7595e3aa1a45f623
> > > compiler:       Debian clang version 15.0.6, GNU ld (GNU Binutils for Debian) 2.40
> > > 
> > > Unfortunately, I don't have any reproducer for this issue yet.
> > > 
> > > Downloadable assets:
> > > disk image: https://storage.googleapis.com/syzbot-assets/27e64d7472ce/disk-2ccbdf43.raw.xz
> > > vmlinux: https://storage.googleapis.com/syzbot-assets/e1c494bb5c9c/vmlinux-2ccbdf43.xz
> > > kernel image: https://storage.googleapis.com/syzbot-assets/752498985a5e/bzImage-2ccbdf43.xz
> > > 
> > > IMPORTANT: if you fix the issue, please add the following tag to the commit:
> > > Reported-by: syzbot+19ec7595e3aa1a45f623@xxxxxxxxxxxxxxxxxxxxxxxxx
> > > 
> > > smc: removing ib device syz0
> > > ------------[ cut here ]------------
> > > WARNING: CPU: 0 PID: 51 at kernel/rcu/srcutree.c:653 cleanup_srcu_struct+0x404/0x4d0 kernel/rcu/srcutree.c:653
> > > Modules linked in:
> > > CPU: 0 PID: 51 Comm: kworker/u8:3 Not tainted 6.10.0-rc3-syzkaller-00044-g2ccbdf43d5e7 #0
> > > Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 06/07/2024
> > > Workqueue: ib-unreg-wq ib_unregister_work
> > > RIP: 0010:cleanup_srcu_struct+0x404/0x4d0 kernel/rcu/srcutree.c:653
> > > Code: 12 80 00 48 c7 03 00 00 00 00 48 83 c4 48 5b 41 5c 41 5d 41 5e 41 5f 5d e9 14 67 34 0a 90 0f 0b 90 eb e7 90 0f 0b 90 eb e1 90 <0f> 0b 90 eb db 90 0f 0b 90 eb 0a 90 0f 0b 90 eb 04 90 0f 0b 90 48
> > > RSP: 0018:ffffc90000bb7970 EFLAGS: 00010202
> > > RAX: 0000000000000001 RBX: ffff88802a1bc980 RCX: 0000000000000002
> > > RDX: 0000000000000000 RSI: 0000000000000008 RDI: ffffe8ffffd74c58
> > > RBP: 0000000000000001 R08: ffffe8ffffd74c5f R09: 1ffffd1ffffae98b
> > > R10: dffffc0000000000 R11: fffff91ffffae98c R12: dffffc0000000000
> > > R13: ffff88802285b5f0 R14: ffff88802285b000 R15: ffff88802a1bc800
> > > FS:  0000000000000000(0000) GS:ffff8880b9400000(0000) knlGS:0000000000000000
> > > CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > > CR2: 00007fa3852cae10 CR3: 000000000e132000 CR4: 0000000000350ef0
> > > Call Trace:
> > >   <TASK>
> > >   ib_uverbs_release_dev+0x4e/0x80 drivers/infiniband/core/uverbs_main.c:136
> > >   device_release+0x9b/0x1c0
> > >   kobject_cleanup lib/kobject.c:689 [inline]
> > >   kobject_release lib/kobject.c:720 [inline]
> > >   kref_put include/linux/kref.h:65 [inline]
> > >   kobject_put+0x231/0x480 lib/kobject.c:737
> > >   remove_client_context+0xb9/0x1e0 drivers/infiniband/core/device.c:776
> > >   disable_device+0x13b/0x360 drivers/infiniband/core/device.c:1282
> > >   __ib_unregister_device+0x6d/0x170 drivers/infiniband/core/device.c:1475
> > >   ib_unregister_work+0x19/0x30 drivers/infiniband/core/device.c:1586
> > >   process_one_work kernel/workqueue.c:3231 [inline]
> > >   process_scheduled_works+0xa2e/0x1830 kernel/workqueue.c:3312
> > >   worker_thread+0x86d/0xd70 kernel/workqueue.c:3393
> > >   kthread+0x2f2/0x390 kernel/kthread.c:389
> > >   ret_from_fork+0x4d/0x80 arch/x86/kernel/process.c:147
> > >   ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
> > >   </TASK>
> > 
> > I see that this is caused by call to ib_unregister_device_queued() as a
> > response to NETDEV_UNREGISTER event, but we don't flush anything before.
> > How can we be sure that ib_device is not used anymore?
> 
> Hi, Leon
> 
> This is the console output:
> 
> https://syzkaller.appspot.com/x/log.txt?x=179e93fe980000
> 
> From the above link, it seems that other devices or subsystems failed
> firstly, then caused this call trace to appear. When other problem occurred,
> the whole kernel system was in mess state.So it is not weird that some
> problems occurred.

Which devices/subsystems failed? I grepped the log and don't see
anything suspicious, before first "------------[ cut here ]------------"
sentence.

> 
> To be simple, the root cause is not in RDMA subsystem.
> 
> I will continue to delve into this problem.
> 
> Zhu Yanjun
> > 
> > Thanks
> 




[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux