Hi Jiayuan,
Thanks for explaining the situation. I will double check this problem.

Best regards,
Longxing Li

Jiayuan Chen [off-list ref] 于2026年6月10日周三 17:26写道：

On 6/10/26 3:14 PM, Longxing Li wrote:

quoted

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/