Re: [syzbot] [kernel?] BUG: sleeping function called from invalid context in static_key_slow_dec

[Florian Westphal]

syzbot <syzbot+b26935466701e56cfdc2@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
> BUG: sleeping function called from invalid context at include/linux/percpu-rwsem.h:49
> in_atomic(): 1, irqs_disabled(): 0, non_block: 0, pid: 16, name: ksoftirqd/0
> preempt_count: 100, expected: 0
> RCU nest depth: 0, expected: 0
> 1 lock held by ksoftirqd/0/16:
>  #0: ffffffff8e937e60 (rcu_callback){....}-{0:0}, at: rcu_lock_acquire include/linux/rcupdate.h:337 [inline]
>  #0: ffffffff8e937e60 (rcu_callback){....}-{0:0}, at: rcu_do_batch kernel/rcu/tree.c:2561 [inline]
>  #0: ffffffff8e937e60 (rcu_callback){....}-{0:0}, at: rcu_core+0xa37/0x17a0 kernel/rcu/tree.c:2823
> Preemption disabled at:
> [<ffffffff81578192>] softirq_handle_begin kernel/softirq.c:395 [inline]
> [<ffffffff81578192>] handle_softirqs+0x122/0x980 kernel/softirq.c:530
> CPU: 0 UID: 0 PID: 16 Comm: ksoftirqd/0 Not tainted 6.12.0-rc6-syzkaller-00203-g5b366eae7193 #0
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 10/30/2024
> 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:8653
>  percpu_down_read include/linux/percpu-rwsem.h:49 [inline]
>  cpus_read_lock+0x1b/0x150 kernel/cpu.c:490
>  __static_key_slow_dec kernel/jump_label.c:320 [inline]
>  static_key_slow_dec+0x49/0xa0 kernel/jump_label.c:336
>  nf_tables_chain_destroy+0x3c4/0x4f0 net/netfilter/nf_tables_api.c:2160
>  __nft_release_basechain_now net/netfilter/nf_tables_api.c:11442 [inline]
>  nft_release_basechain_rcu+0x3fc/0x550 net/netfilter/nf_tables_api.c:11454

nf_tables_chain_destroy can sleep via the static key.

I suggest to remove the basechain stats, this was a mistake all along.

Alternative is to defer to work queue or see if replacing the static key
with a deferred static key, that should place the problematic jump
patching to work queue too.

But I'd rather axe all of the basechain stat stuff.