Re: [Kernel Bug] INFO: task hung in xt_find_table

[Jiayuan Chen <jiayuan.chen@linux.dev>]

On 6/10/26 3:14 PM, Longxing Li wrote:
> sorry for not containing report plain text in last email. the report
> is as follows:
>
> INFO: task syz-executor.4:42949 blocked for more than 143 seconds.
>        Not tainted 7.0.6 #1
> "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
> task:syz-executor.4  state:D stack:26456 pid:42949 tgid:42937
> ppid:9759   task_flags:0x400140 flags:0x00080002
> Call Trace:
>   <TASK>
>   context_switch kernel/sched/core.c:5298 [inline]
>   __schedule+0x1006/0x5f00 kernel/sched/core.c:6911
>   __schedule_loop kernel/sched/core.c:6993 [inline]
>   schedule+0xe7/0x3a0 kernel/sched/core.c:7008
>   schedule_preempt_disabled+0x13/0x30 kernel/sched/core.c:7065
>   __mutex_lock_common kernel/locking/mutex.c:692 [inline]
>   __mutex_lock+0xd9e/0x1df0 kernel/locking/mutex.c:776
>   xt_find_table+0x59/0x1a0 net/netfilter/x_tables.c:1245
>   ip6t_unregister_table_exit+0x22/0x50 net/ipv6/netfilter/ip6_tables.c:1808
>   ops_exit_list net/core/net_namespace.c:199 [inline]
>   ops_undo_list+0x2dd/0xa50 net/core/net_namespace.c:252
>   setup_net+0x1f3/0x3a0 net/core/net_namespace.c:462
>   copy_net_ns+0x351/0x7c0 net/core/net_namespace.c:579
>   create_new_namespaces+0x3f6/0xac0 kernel/nsproxy.c:130
>   copy_namespaces+0x45c/0x580 kernel/nsproxy.c:195
>   copy_process+0x30cc/0x76d0 kernel/fork.c:2227
>   kernel_clone+0xea/0x8f0 kernel/fork.c:2655
>   __do_sys_clone+0xce/0x120 kernel/fork.c:2796
>   do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
>   do_syscall_64+0x11b/0xf80 arch/x86/entry/syscall_64.c:94
>   entry_SYSCALL_64_after_hwframe+0x77/0x7f
> RIP: 0033:0x471ecd
> RSP: 002b:00007f51f163e008 EFLAGS: 00000202 ORIG_RAX: 0000000000000038
> RAX: ffffffffffffffda RBX: 000000000059bf80 RCX: 0000000000471ecd
> RDX: 0000000000000000 RSI: 0000000000000000 RDI: 0000000040080020
> RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000
> R10: 0000000000000000 R11: 0000000000000202 R12: 000000000059bf8c
> R13: 000000000000000b R14: 000000000059bf80 R15: 00007f51f161e000
>   </TASK>



This is not a deadlock — there's no lock cycle.

The runner is simply under heavy pressure on all three axes: CPU (zswap 
compression) + memory (direct reclaim) + IO (swap).

The hung task is just a victim. The actual holder is another task that 
took the mutex and then fell into direct reclaim.

Likely stack of the holder:
get_entries
   xt_find_table_lock
   copy_entries_to_user
     alloc_counters
        vzalloc  -> direct reclaim

"INFO: task hung" reports of this kind are common on the official 
syzkaller dashboard https://syzkaller.appspot.com/upstream/