[syzbot] [wireless?] BUG: sleeping function called from invalid context in wext_netdev_notifier_call

[syzbot]

Hello,

syzbot found the following issue on:

HEAD commit: 4c49f38e20a5 net: stmmac: fix TSO DMA API usage causing oops
git tree: net
console output: https://syzkaller.appspot.com/x/log.txt?x=11614820580000
kernel config: https://syzkaller.appspot.com/x/.config?x=1362a5aee630ff34
dashboard link: https://syzkaller.appspot.com/bug?extid=3647b9259b77c1bb8e94
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/09256902989e/disk-4c49f38e.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/2b41c0f5233f/vmlinux-4c49f38e.xz
kernel image: https://storage.googleapis.com/syzbot-assets/7bb9fdcd5331/bzImage-4c49f38e.xz

IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+3647b9...@syzkaller.appspotmail.com

BUG: sleeping function called from invalid context at kernel/locking/rwsem.c:1523
in_atomic(): 0, irqs_disabled(): 0, non_block: 0, pid: 12894, name: kworker/u8:18
preempt_count: 0, expected: 0
RCU nest depth: 1, expected: 0
INFO: lockdep is turned off.
CPU: 1 UID: 0 PID: 12894 Comm: kworker/u8:18 Not tainted 6.13.0-rc1-syzkaller-00183-g4c49f38e20a5 #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
Workqueue: bond0 bond_mii_monitor
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
__might_resched+0x5d4/0x780 kernel/sched/core.c:8758
down_read+0x8e/0xa40 kernel/locking/rwsem.c:1523
wireless_nlevent_flush net/wireless/wext-core.c:351 [inline]
wext_netdev_notifier_call+0x1f/0x120 net/wireless/wext-core.c:371
notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85
netdev_state_change+0x11f/0x1a0 net/core/dev.c:1378
linkwatch_do_dev+0x112/0x170 net/core/link_watch.c:182
ethtool_op_get_link+0x15/0x60 net/ethtool/ioctl.c:62
bond_check_dev_link+0x1f1/0x3f0 drivers/net/bonding/bond_main.c:873
bond_miimon_inspect drivers/net/bonding/bond_main.c:2740 [inline]
bond_mii_monitor+0x49a/0x3170 drivers/net/bonding/bond_main.c:2962
process_one_work kernel/workqueue.c:3229 [inline]
process_scheduled_works+0xa66/0x1840 kernel/workqueue.c:3310
worker_thread+0x870/0xd30 kernel/workqueue.c:3391
kthread+0x2f0/0x390 kernel/kthread.c:389
ret_from_fork+0x4b/0x80 arch/x86/kernel/process.c:147
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:244
</TASK>
bridge0: port 2(bridge_slave_1) entered blocking state
bridge0: port 2(bridge_slave_1) entered forwarding state


---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzk...@googlegroups.com.

syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title

If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)

If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report

If you want to undo deduplication, reply with:
#syz undup

[Johannes Berg]

On Wed, 2024-12-11 at 20:41 -0800, syzbot wrote:
> CPU: 1 UID: 0 PID: 12894 Comm: kworker/u8:18 Not tainted 6.13.0-rc1-syzkaller-00183-g4c49f38e20a5 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 09/13/2024
> Workqueue: bond0 bond_mii_monitor
> Call Trace:
> <TASK>
> __dump_stack lib/dump_stack.c:94 [inline]
> dump_stack_lvl+0x241/0x360 lib/dump_stack.c:120
> __might_resched+0x5d4/0x780 kernel/sched/core.c:8758
> down_read+0x8e/0xa40 kernel/locking/rwsem.c:1523
> wireless_nlevent_flush net/wireless/wext-core.c:351 [inline]
> wext_netdev_notifier_call+0x1f/0x120 net/wireless/wext-core.c:371
> notifier_call_chain+0x1a5/0x3f0 kernel/notifier.c:85
> netdev_state_change+0x11f/0x1a0 net/core/dev.c:1378
> linkwatch_do_dev+0x112/0x170 net/core/link_watch.c:182
> ethtool_op_get_link+0x15/0x60 net/ethtool/ioctl.c:62
> bond_check_dev_link+0x1f1/0x3f0 drivers/net/bonding/bond_main.c:873
> bond_miimon_inspect drivers/net/bonding/bond_main.c:2740 [inline]
> bond_mii_monitor+0x49a/0x3170 drivers/net/bonding/bond_main.c:2962

Yeah this isn't new. I thought we were going to just squash this with

https://lore.kernel.org/netdev/2730097.1721581672@famine/

Whatever came of that?

johannes

[Kuniyuki Iwashima]

From: Johannes Berg <joha...@sipsolutions.net>
Date: Thu, 12 Dec 2024 09:52:44 +0100

Now I remember I forgot to respin this patch.
https://lore.kernel.org/linux-wireless/20241014205543...@amazon.com/

If the issue above is still not fixed, I will respin it on
wireless.git with Fixes tag.

What do you think ?

[Johannes Berg]

Wait, that's not related at all? The bonding issue still is that it
calls ethtool ops under RCU but ethtool ops can sleep. That issue has
nothing to do with the wext nlevent namespace-ification?


We can still do the namespace thing for wext nlevent, but it's not going
to fix this issue, and I don't think we need to on wireless (rather than
wireless-next)

johannes

[Kuniyuki Iwashima]

From: Johannes Berg <joha...@sipsolutions.net>
Date: Fri, 13 Dec 2024 09:39:04 +0100

Ah okay, I thought removing the mutex there was another option
to silence it, but I didn't check other places.

>
>
> We can still do the namespace thing for wext nlevent, but it's not going
> to fix this issue, and I don't think we need to on wireless (rather than
> wireless-next)

I see, will post to -next.

Thanks!