From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> Date: Fri, 13 Dec 2024 09:39:04 +0100 > On Fri, 2024-12-13 at 17:36 +0900, Kuniyuki Iwashima wrote: > > From: Johannes Berg <johannes@xxxxxxxxxxxxxxxx> > > Date: Thu, 12 Dec 2024 09:52:44 +0100 > > > 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? > > > > Now I remember I forgot to respin this patch. > > https://lore.kernel.org/linux-wireless/20241014205543.94787-4-kuniyu@xxxxxxxxxx/ > > > > If the issue above is still not fixed, I will respin it on > > wireless.git with Fixes tag. > > 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? 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!
