Search Linux Wireless

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

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

 



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?


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





[Index of Archives]     [Linux Host AP]     [ATH6KL]     [Linux Wireless Personal Area Network]     [Linux Bluetooth]     [Wireless Regulations]     [Linux Netdev]     [Kernel Newbies]     [Linux Kernel]     [IDE]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite Hiking]     [MIPS Linux]     [ARM Linux]     [Linux RAID]

  Powered by Linux