Re: [syzbot] INFO: task hung in reg_check_chans_work (3)

[Florian Westphal <fw@strlen.de>]

Jakub Kicinski <kuba@kernel.org> wrote:
> netfilter... rtnl.. workqueue... let's CC Florian..

Thanks.

> > HEAD commit:    a4e6f95a891a Merge tag 'pinctrl-v5.15-2' of git://git.kern..

This HEAD doesn't include

7970a19b71044bf4dc2c1becc200275bdf1884d4
netfilter: nf_nat_masquerade: defer conntrack walk to work queue

so, with a bit of luck this is already resolved.

> >  context_switch kernel/sched/core.c:4940 [inline]
> >  __schedule+0x940/0x26f0 kernel/sched/core.c:6287
> >  schedule+0xd3/0x270 kernel/sched/core.c:6366
> >  schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:6425
> >  __mutex_lock_common kernel/locking/mutex.c:669 [inline]
> >  __mutex_lock+0xa34/0x12f0 kernel/locking/mutex.c:729
> >  reg_check_chans_work+0x83/0xe10 net/wireless/reg.c:2423
> >  process_one_work+0x9bf/0x16b0 kernel/workqueue.c:2297

workqueue tries to rtnl_lock()...

> > task:syz-executor.0  state:D stack:27152 pid:17047 ppid: 13518 flags:0x00004004
> > Call Trace:
> >  context_switch kernel/sched/core.c:4940 [inline]
> >  __schedule+0x940/0x26f0 kernel/sched/core.c:6287
> >  schedule+0xd3/0x270 kernel/sched/core.c:6366
> >  schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:6425
> >  __mutex_lock_common kernel/locking/mutex.c:669 [inline]
> >  __mutex_lock+0xa34/0x12f0 kernel/locking/mutex.c:729
> >  rtnl_lock net/core/rtnetlink.c:72 [inline]
> >  rtnetlink_rcv_msg+0x3be/0xb80 net/core/rtnetlink.c:5569

... syz-executor as well ...

> > task:syz-executor.4  state:D stack:27216 pid:17052 ppid:  6665 flags:0x00004004
> > Call Trace:
> >  context_switch kernel/sched/core.c:4940 [inline]
> >  __schedule+0x940/0x26f0 kernel/sched/core.c:6287
> >  schedule+0xd3/0x270 kernel/sched/core.c:6366
> >  schedule_preempt_disabled+0xf/0x20 kernel/sched/core.c:6425
> >  __mutex_lock_common kernel/locking/mutex.c:669 [inline]
> >  __mutex_lock+0xa34/0x12f0 kernel/locking/mutex.c:729
> >  rtnl_lock net/core/rtnetlink.c:72 [inline]
> >  rtnetlink_rcv_msg+0x3be/0xb80 net/core/rtnetlink.c:5569
> >  netlink_rcv_skb+0x153/0x420 net/netlink/af_netlink.c:2504

... and another syz-executor instance ...

> >  __local_bh_enable_ip+0xcd/0x120 kernel/softirq.c:371
> >  local_bh_enable include/linux/bottom_half.h:32 [inline]
> >  get_next_corpse net/netfilter/nf_conntrack_core.c:2252 [inline]
> >  nf_ct_iterate_cleanup+0x15a/0x450 net/netfilter/nf_conntrack_core.c:2275
> >  nf_ct_iterate_cleanup_net net/netfilter/nf_conntrack_core.c:2363 [inline]
> >  nf_ct_iterate_cleanup_net+0x236/0x400 net/netfilter/nf_conntrack_core.c:2347
> >  masq_device_event+0xae/0xe0 net/netfilter/nf_nat_masquerade.c:88
> >  notifier_call_chain+0xb5/0x200 kernel/notifier.c:83

... and rtnl is held by notifier call chain.

This is no longer the case in current net head,
nf_ct_iterate_cleanup() runs from workqueue without rtnl locked.