* [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
@ 2026-03-17 17:33 syzbot
2026-08-26 19:33 ` syzbot
0 siblings, 1 reply; 28+ messages in thread
From: syzbot @ 2026-03-17 17:33 UTC (permalink / raw)
To: driver-core, gregkh, linux-kernel, syzkaller-bugs, tj
Hello,
syzbot found the following issue on:
HEAD commit: 2d1373e4246d Merge tag 'for-7.0-rc4-tag' of git://git.kern..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=13ab3406580000
kernel config: https://syzkaller.appspot.com/x/.config?x=45cb3c58fd963c27
dashboard link: https://syzkaller.appspot.com/bug?extid=dd764a450d93885d847f
compiler: Debian clang version 21.1.8 (++20251221033036+2078da43e25a-1~exp1~20251221153213.50), Debian LLD 21.1.8
Unfortunately, I don't have any reproducer for this issue yet.
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/b8f9fdb26fea/disk-2d1373e4.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/1f20580466c5/vmlinux-2d1373e4.xz
kernel image: https://storage.googleapis.com/syzbot-assets/f051fb6711e4/bzImage-2d1373e4.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+dd764a450d93885d847f@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Tainted: G L
------------------------------------------------------
kworker/u9:1/11370 is trying to acquire lock:
ffff888019c4f2c0 (&root->kernfs_iattr_rwsem){++++}-{4:4}, at: kernfs_link_sibling+0x46c/0x540 fs/kernfs/dir.c:394
but task is already holding lock:
ffff888019c4f238 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_add_one+0x41/0x5c0 fs/kernfs/dir.c:796
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #10 (&root->kernfs_rwsem){++++}-{4:4}:
down_write+0x3a/0x50 kernel/locking/rwsem.c:1590
kernfs_add_one+0x41/0x5c0 fs/kernfs/dir.c:796
kernfs_create_dir_ns+0xde/0x130 fs/kernfs/dir.c:1098
internal_create_group+0x425/0x1180 fs/sysfs/group.c:176
cpuhp_invoke_callback+0x445/0x860 kernel/cpu.c:194
cpuhp_issue_call+0x430/0x7a0 kernel/cpu.c:-1
__cpuhp_setup_state_cpuslocked+0x3d9/0x6b0 kernel/cpu.c:2507
__cpuhp_setup_state+0x3f/0x60 kernel/cpu.c:2536
do_one_initcall+0x250/0x8d0 init/main.c:1382
do_initcall_level+0x104/0x190 init/main.c:1444
do_initcalls+0x59/0xa0 init/main.c:1460
kernel_init_freeable+0x2a6/0x3e0 init/main.c:1692
kernel_init+0x1d/0x1d0 init/main.c:1582
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #9 (cpuhp_state_mutex){+.+.}-{4:4}:
-> #8 (cpu_hotplug_lock){++++}-{0:0}:
percpu_down_read_internal include/linux/percpu-rwsem.h:53 [inline]
percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
cpus_read_lock+0x42/0x160 kernel/cpu.c:490
static_key_slow_inc+0x12/0x30 kernel/jump_label.c:190
tcp_md5_do_add+0x1d4/0x390 net/ipv4/tcp_ipv4.c:1431
tcp_v6_parse_md5_keys+0x562/0x680 net/ipv6/tcp_ipv6.c:-1
do_tcp_setsockopt+0x12ee/0x2060 net/ipv4/tcp.c:4134
do_sock_setsockopt+0x17c/0x1b0 net/socket.c:2322
__sys_setsockopt net/socket.c:2347 [inline]
__do_sys_setsockopt net/socket.c:2353 [inline]
__se_sys_setsockopt net/socket.c:2350 [inline]
__x64_sys_setsockopt+0x143/0x1b0 net/socket.c:2350
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #7 (sk_lock-AF_INET6){+.+.}-{0:0}:
lock_sock_nested+0x3e/0x130 net/core/sock.c:3780
lock_sock include/net/sock.h:1709 [inline]
inet_shutdown+0x6a/0x390 net/ipv4/af_inet.c:919
nbd_mark_nsock_dead+0x2e9/0x560 drivers/block/nbd.c:318
recv_work+0x1c9d/0x1dc0 drivers/block/nbd.c:1021
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #6 (&nsock->tx_lock){+.+.}-{4:4}:
__mutex_lock_common kernel/locking/rtmutex_api.c:533 [inline]
mutex_lock_nested+0x5a/0x1d0 kernel/locking/rtmutex_api.c:552
nbd_handle_cmd drivers/block/nbd.c:1143 [inline]
nbd_queue_rq+0x37b/0x1100 drivers/block/nbd.c:1207
blk_mq_dispatch_rq_list+0xa77/0x1910 block/blk-mq.c:2148
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xddb/0x1610 block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xda/0x1a0 block/blk-mq-sched.c:329
blk_mq_run_hw_queue+0x368/0x520 block/blk-mq.c:2386
blk_mq_dispatch_list+0xd1f/0xe20 include/linux/spinlock_rt.h:-1
blk_mq_flush_plug_list+0x48d/0x570 block/blk-mq.c:2997
__blk_flush_plug+0x3ed/0x4d0 block/blk-core.c:1230
blk_finish_plug block/blk-core.c:1257 [inline]
__submit_bio+0x28d/0x580 block/blk-core.c:649
__submit_bio_noacct_mq block/blk-core.c:722 [inline]
submit_bio_noacct_nocheck+0x2f4/0xa70 block/blk-core.c:753
submit_bh fs/buffer.c:2826 [inline]
block_read_full_folio+0x599/0x830 fs/buffer.c:2444
filemap_read_folio+0x137/0x3b0 mm/filemap.c:2501
do_read_cache_folio+0x2bf/0x560 mm/filemap.c:4101
read_mapping_folio include/linux/pagemap.h:1028 [inline]
read_part_sector+0xb8/0x2b0 block/partitions/core.c:723
adfspart_check_ICS+0xa5/0xa40 block/partitions/acorn.c:360
check_partition block/partitions/core.c:142 [inline]
blk_add_partitions block/partitions/core.c:590 [inline]
bdev_disk_changed+0x7ba/0x1550 block/partitions/core.c:694
blkdev_get_whole+0x2e5/0x480 block/bdev.c:764
bdev_open+0x31e/0xcc0 block/bdev.c:973
blkdev_open+0x485/0x620 block/fops.c:697
do_dentry_open+0x83d/0x13e0 fs/open.c:949
vfs_open+0x3b/0x350 fs/open.c:1081
do_open fs/namei.c:4671 [inline]
path_openat+0x2e43/0x38a0 fs/namei.c:4830
do_file_open+0x23e/0x4a0 fs/namei.c:4859
do_sys_openat2+0x113/0x200 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x138/0x170 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #5 (&cmd->lock){+.+.}-{4:4}:
__mutex_lock_common kernel/locking/rtmutex_api.c:533 [inline]
mutex_lock_nested+0x5a/0x1d0 kernel/locking/rtmutex_api.c:552
nbd_queue_rq+0xc6/0x1100 drivers/block/nbd.c:1199
blk_mq_dispatch_rq_list+0xa77/0x1910 block/blk-mq.c:2148
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xddb/0x1610 block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xda/0x1a0 block/blk-mq-sched.c:329
blk_mq_run_hw_queue+0x368/0x520 block/blk-mq.c:2386
blk_mq_dispatch_list+0xd1f/0xe20 include/linux/spinlock_rt.h:-1
blk_mq_flush_plug_list+0x48d/0x570 block/blk-mq.c:2997
__blk_flush_plug+0x3ed/0x4d0 block/blk-core.c:1230
blk_finish_plug block/blk-core.c:1257 [inline]
__submit_bio+0x28d/0x580 block/blk-core.c:649
__submit_bio_noacct_mq block/blk-core.c:722 [inline]
submit_bio_noacct_nocheck+0x2f4/0xa70 block/blk-core.c:753
submit_bh fs/buffer.c:2826 [inline]
block_read_full_folio+0x599/0x830 fs/buffer.c:2444
filemap_read_folio+0x137/0x3b0 mm/filemap.c:2501
do_read_cache_folio+0x2bf/0x560 mm/filemap.c:4101
read_mapping_folio include/linux/pagemap.h:1028 [inline]
read_part_sector+0xb8/0x2b0 block/partitions/core.c:723
adfspart_check_ICS+0xa5/0xa40 block/partitions/acorn.c:360
check_partition block/partitions/core.c:142 [inline]
blk_add_partitions block/partitions/core.c:590 [inline]
bdev_disk_changed+0x7ba/0x1550 block/partitions/core.c:694
blkdev_get_whole+0x2e5/0x480 block/bdev.c:764
bdev_open+0x31e/0xcc0 block/bdev.c:973
blkdev_open+0x485/0x620 block/fops.c:697
do_dentry_open+0x83d/0x13e0 fs/open.c:949
vfs_open+0x3b/0x350 fs/open.c:1081
do_open fs/namei.c:4671 [inline]
path_openat+0x2e43/0x38a0 fs/namei.c:4830
do_file_open+0x23e/0x4a0 fs/namei.c:4859
do_sys_openat2+0x113/0x200 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x138/0x170 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #4 (set->srcu){.+.+}-{0:0}:
srcu_lock_sync include/linux/srcu.h:199 [inline]
__synchronize_srcu+0xca/0x3e0 kernel/rcu/srcutree.c:1505
elevator_switch+0x1e8/0x7a0 block/elevator.c:576
elevator_change+0x2cc/0x450 block/elevator.c:681
elevator_set_default+0x36c/0x430 block/elevator.c:754
blk_register_queue+0x366/0x430 block/blk-sysfs.c:946
__add_disk+0x677/0xd50 block/genhd.c:528
add_disk_fwnode+0xfb/0x480 block/genhd.c:597
add_disk include/linux/blkdev.h:785 [inline]
nbd_dev_add+0x72c/0xb50 drivers/block/nbd.c:1984
nbd_init+0x168/0x1f0 drivers/block/nbd.c:2692
do_one_initcall+0x250/0x8d0 init/main.c:1382
do_initcall_level+0x104/0x190 init/main.c:1444
do_initcalls+0x59/0xa0 init/main.c:1460
kernel_init_freeable+0x2a6/0x3e0 init/main.c:1692
kernel_init+0x1d/0x1d0 init/main.c:1582
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #3 (&q->elevator_lock){+.+.}-{4:4}:
__mutex_lock_common kernel/locking/rtmutex_api.c:533 [inline]
mutex_lock_nested+0x5a/0x1d0 kernel/locking/rtmutex_api.c:552
elevator_change+0x1b3/0x450 block/elevator.c:679
elevator_set_none+0xb5/0x140 block/elevator.c:769
blk_mq_elv_switch_none block/blk-mq.c:5110 [inline]
__blk_mq_update_nr_hw_queues block/blk-mq.c:5155 [inline]
blk_mq_update_nr_hw_queues+0x607/0x1a80 block/blk-mq.c:5220
nbd_start_device+0x17f/0xb20 drivers/block/nbd.c:1489
nbd_genl_connect+0x1651/0x1c80 drivers/block/nbd.c:2239
genl_family_rcv_msg_doit+0x22a/0x330 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x61c/0x7a0 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x831/0x9f0 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x94c/0x9c0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #2 (&q->q_usage_counter(io)#75){++++}-{0:0}:
blk_alloc_queue+0x54e/0x690 block/blk-core.c:461
blk_mq_alloc_queue block/blk-mq.c:4429 [inline]
__blk_mq_alloc_disk+0x197/0x390 block/blk-mq.c:4476
nbd_dev_add+0x499/0xb50 drivers/block/nbd.c:1954
nbd_genl_connect+0x965/0x1c80 drivers/block/nbd.c:2125
genl_family_rcv_msg_doit+0x22a/0x330 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x61c/0x7a0 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x232/0x4b0 net/netlink/af_netlink.c:2550
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1318 [inline]
netlink_unicast+0x831/0x9f0 net/netlink/af_netlink.c:1344
netlink_sendmsg+0x813/0xb40 net/netlink/af_netlink.c:1894
sock_sendmsg_nosec net/socket.c:727 [inline]
__sock_sendmsg net/socket.c:742 [inline]
____sys_sendmsg+0x94c/0x9c0 net/socket.c:2592
___sys_sendmsg+0x2a5/0x360 net/socket.c:2646
__sys_sendmsg net/socket.c:2678 [inline]
__do_sys_sendmsg net/socket.c:2683 [inline]
__se_sys_sendmsg net/socket.c:2681 [inline]
__x64_sys_sendmsg+0x1c3/0x2a0 net/socket.c:2681
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #1 (fs_reclaim){+.+.}-{0:0}:
__fs_reclaim_acquire mm/page_alloc.c:4348 [inline]
fs_reclaim_acquire+0x71/0x100 mm/page_alloc.c:4362
might_alloc include/linux/sched/mm.h:317 [inline]
slab_pre_alloc_hook mm/slub.c:4489 [inline]
slab_alloc_node mm/slub.c:4843 [inline]
kmem_cache_alloc_noprof+0x44/0x680 mm/slub.c:4873
__kernfs_iattrs+0xdf/0x340 fs/kernfs/inode.c:36
kernfs_iattrs fs/kernfs/inode.c:61 [inline]
__kernfs_setattr fs/kernfs/inode.c:74 [inline]
kernfs_iop_setattr+0xea/0x3f0 fs/kernfs/inode.c:128
notify_change+0xc18/0xf60 fs/attr.c:556
do_truncate+0x1c2/0x250 fs/open.c:68
handle_truncate fs/namei.c:4279 [inline]
do_open fs/namei.c:4675 [inline]
path_openat+0x2fc4/0x38a0 fs/namei.c:4830
do_file_open+0x23e/0x4a0 fs/namei.c:4859
do_sys_openat2+0x113/0x200 fs/open.c:1366
do_sys_open fs/open.c:1372 [inline]
__do_sys_openat fs/open.c:1388 [inline]
__se_sys_openat fs/open.c:1383 [inline]
__x64_sys_openat+0x138/0x170 fs/open.c:1383
do_syscall_x64 arch/x86/entry/syscall_64.c:63 [inline]
do_syscall_64+0x14d/0xf80 arch/x86/entry/syscall_64.c:94
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&root->kernfs_iattr_rwsem){++++}-{4:4}:
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
down_write+0x3a/0x50 kernel/locking/rwsem.c:1590
kernfs_link_sibling+0x46c/0x540 fs/kernfs/dir.c:394
kernfs_add_one+0x1ca/0x5c0 fs/kernfs/dir.c:815
kernfs_create_dir_ns+0xde/0x130 fs/kernfs/dir.c:1098
sysfs_create_dir_ns+0x12f/0x2a0 fs/sysfs/dir.c:59
create_dir lib/kobject.c:73 [inline]
kobject_add_internal+0x631/0xd10 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_add+0x163/0x240 lib/kobject.c:426
device_add+0x408/0xb80 drivers/base/core.c:3627
hci_conn_add_sysfs+0xd5/0x210 net/bluetooth/hci_sysfs.c:48
hci_conn_complete_evt+0x77a/0x11d0 net/bluetooth/hci_event.c:3195
hci_event_func net/bluetooth/hci_event.c:7784 [inline]
hci_event_packet+0x805/0x12c0 net/bluetooth/hci_event.c:7838
hci_rx_work+0x3ee/0x1030 net/bluetooth/hci_core.c:4077
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
&root->kernfs_iattr_rwsem --> cpuhp_state_mutex --> &root->kernfs_rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&root->kernfs_rwsem);
lock(cpuhp_state_mutex);
lock(&root->kernfs_rwsem);
lock(&root->kernfs_iattr_rwsem);
*** DEADLOCK ***
4 locks held by kworker/u9:1/11370:
#0: ffff888033cf8938 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3251 [inline]
#0: ffff888033cf8938 ((wq_completion)hci0#2){+.+.}-{0:0}, at: process_scheduled_works+0xa52/0x18c0 kernel/workqueue.c:3359
#1: ffffc90005fefc40 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_one_work kernel/workqueue.c:3252 [inline]
#1: ffffc90005fefc40 ((work_completion)(&hdev->rx_work)){+.+.}-{0:0}, at: process_scheduled_works+0xa8d/0x18c0 kernel/workqueue.c:3359
#2: ffff8880392140b0 (&hdev->lock){+.+.}-{4:4}, at: hci_conn_complete_evt+0xbb/0x11d0 net/bluetooth/hci_event.c:3113
#3: ffff888019c4f238 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_add_one+0x41/0x5c0 fs/kernfs/dir.c:796
stack backtrace:
CPU: 0 UID: 0 PID: 11370 Comm: kworker/u9:1 Tainted: G L syzkaller #0 PREEMPT_{RT,(full)}
Tainted: [L]=SOFTLOCKUP
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 02/12/2026
Workqueue: hci0 hci_rx_work
Call Trace:
<TASK>
dump_stack_lvl+0xe8/0x150 lib/dump_stack.c:120
print_circular_bug+0x2e1/0x300 kernel/locking/lockdep.c:2043
check_noncircular+0x12e/0x150 kernel/locking/lockdep.c:2175
check_prev_add kernel/locking/lockdep.c:3165 [inline]
check_prevs_add kernel/locking/lockdep.c:3284 [inline]
validate_chain kernel/locking/lockdep.c:3908 [inline]
__lock_acquire+0x15a5/0x2cf0 kernel/locking/lockdep.c:5237
lock_acquire+0xf0/0x2e0 kernel/locking/lockdep.c:5868
down_write+0x3a/0x50 kernel/locking/rwsem.c:1590
kernfs_link_sibling+0x46c/0x540 fs/kernfs/dir.c:394
kernfs_add_one+0x1ca/0x5c0 fs/kernfs/dir.c:815
kernfs_create_dir_ns+0xde/0x130 fs/kernfs/dir.c:1098
sysfs_create_dir_ns+0x12f/0x2a0 fs/sysfs/dir.c:59
create_dir lib/kobject.c:73 [inline]
kobject_add_internal+0x631/0xd10 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_add+0x163/0x240 lib/kobject.c:426
device_add+0x408/0xb80 drivers/base/core.c:3627
hci_conn_add_sysfs+0xd5/0x210 net/bluetooth/hci_sysfs.c:48
hci_conn_complete_evt+0x77a/0x11d0 net/bluetooth/hci_event.c:3195
hci_event_func net/bluetooth/hci_event.c:7784 [inline]
hci_event_packet+0x805/0x12c0 net/bluetooth/hci_event.c:7838
hci_rx_work+0x3ee/0x1030 net/bluetooth/hci_core.c:4077
process_one_work kernel/workqueue.c:3276 [inline]
process_scheduled_works+0xb6e/0x18c0 kernel/workqueue.c:3359
worker_thread+0xa53/0xfc0 kernel/workqueue.c:3440
kthread+0x388/0x470 kernel/kthread.c:436
ret_from_fork+0x51e/0xb90 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
2026-03-17 17:33 [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2) syzbot
@ 2026-08-26 19:33 ` syzbot
2026-08-26 22:49 ` Hillf Danton
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: syzbot @ 2026-08-26 19:33 UTC (permalink / raw)
To: bugs, davidkrehwinkel, discussions, driver-core, gregkh,
linux-kernel, lore, mail, syzkaller-bugs, tj, vrp-test
syzbot has found a reproducer for the following issue on:
HEAD commit: 818bebeb63dd drm/xe: Don't hand out the flat CCS storage a..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=10059625580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ccca94d2c01b9e78
dashboard link: https://syzkaller.appspot.com/bug?extid=dd764a450d93885d847f
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13de8d49580000
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+dd764a450d93885d847f@syzkaller.appspotmail.com
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
kworker/3:0/34 is trying to acquire lock:
ffff88801d6a5a10 (&root->kernfs_iattr_rwsem){++++}-{4:4}, at: kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
but task is already holding lock:
ffff88801d6a5980 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #9 (&root->kernfs_rwsem){++++}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
internal_create_group+0x36f/0xfb0 fs/sysfs/group.c:176
cpuhp_invoke_callback+0x3b4/0x9a0 kernel/cpu.c:194
cpuhp_issue_call+0x1b8/0x970 kernel/cpu.c:2354
__cpuhp_setup_state_cpuslocked+0x431/0x880 kernel/cpu.c:2507
__cpuhp_setup_state+0xf7/0x2f0 kernel/cpu.c:2536
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #8 (cpuhp_state_mutex){+.+.}-{4:4}:
-> #7 (cpu_hotplug_lock){++++}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
percpu_down_read_internal include/linux/percpu-rwsem.h:53 [inline]
percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
cpus_read_lock+0x42/0x170 kernel/cpu.c:490
static_key_slow_inc+0x12/0x30 kernel/jump_label.c:190
nbd_genl_reconnect_sock_cb+0x39f/0x990 drivers/block/nbd.c:1377
nbd_genl_foreach_sock+0x2ab/0x3e0 drivers/block/nbd.c:2152
nbd_genl_reconfigure+0x861/0xde0 drivers/block/nbd.c:2477
genl_family_rcv_msg_doit+0x214/0x300 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x560/0x800 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2556
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec net/socket.c:800 [inline]
__sock_sendmsg net/socket.c:815 [inline]
__sys_sendto+0x48b/0x4e0 net/socket.c:2281
__do_sys_sendto net/socket.c:2288 [inline]
__se_sys_sendto net/socket.c:2284 [inline]
__x64_sys_sendto+0xe0/0x1c0 net/socket.c:2284
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #6 (&nsock->tx_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
nbd_handle_cmd drivers/block/nbd.c:1143 [inline]
nbd_queue_rq+0x42d/0xfa0 drivers/block/nbd.c:1207
blk_mq_dispatch_rq_list+0x428/0x1e60 block/blk-mq.c:2117
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xcea/0x1620 block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xd7/0x1c0 block/blk-mq-sched.c:329
blk_mq_run_work_fn+0x135/0x380 block/blk-mq.c:2531
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #5 (&cmd->lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
nbd_queue_rq+0xba/0xfa0 drivers/block/nbd.c:1199
blk_mq_dispatch_rq_list+0x428/0x1e60 block/blk-mq.c:2117
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xcea/0x1620 block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xd7/0x1c0 block/blk-mq-sched.c:329
blk_mq_run_work_fn+0x135/0x380 block/blk-mq.c:2531
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #4 (set->srcu){.+.+}-{0:0}:
lock_sync kernel/locking/lockdep.c:5934 [inline]
lock_sync+0x9d/0x110 kernel/locking/lockdep.c:5922
srcu_lock_sync include/linux/srcu.h:199 [inline]
__synchronize_srcu+0xa2/0x300 kernel/rcu/srcutree.c:1481
blk_mq_wait_quiesce_done block/blk-mq.c:284 [inline]
blk_mq_wait_quiesce_done block/blk-mq.c:281 [inline]
blk_mq_quiesce_queue block/blk-mq.c:304 [inline]
blk_mq_quiesce_queue+0x149/0x1c0 block/blk-mq.c:299
elevator_switch+0x17b/0x7e0 block/elevator.c:576
elevator_change+0x352/0x530 block/elevator.c:681
elevator_set_default+0x29e/0x360 block/elevator.c:754
blk_register_queue+0x48e/0x630 block/blk-sysfs.c:992
__add_disk+0x73f/0xe40 block/genhd.c:524
add_disk_fwnode+0x118/0x480 block/genhd.c:593
add_disk include/linux/blkdev.h:798 [inline]
nbd_dev_add+0x779/0xb10 drivers/block/nbd.c:2026
nbd_init+0x2c5/0x2e0 drivers/block/nbd.c:2743
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #3 (&q->elevator_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
elevator_change+0x1bc/0x530 block/elevator.c:679
elevator_set_none+0x92/0xf0 block/elevator.c:769
blk_mq_elv_switch_none block/blk-mq.c:5102 [inline]
__blk_mq_update_nr_hw_queues block/blk-mq.c:5147 [inline]
blk_mq_update_nr_hw_queues+0x4c1/0x15f0 block/blk-mq.c:5212
nbd_start_device+0x1a6/0xbd0 drivers/block/nbd.c:1530
nbd_genl_connect+0xfc2/0x1760 drivers/block/nbd.c:2310
genl_family_rcv_msg_doit+0x214/0x300 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x560/0x800 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2556
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec net/socket.c:800 [inline]
__sock_sendmsg net/socket.c:815 [inline]
__sys_sendto+0x48b/0x4e0 net/socket.c:2281
__do_sys_sendto net/socket.c:2288 [inline]
__se_sys_sendto net/socket.c:2284 [inline]
__x64_sys_sendto+0xe0/0x1c0 net/socket.c:2284
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #2 (&q->q_usage_counter(io)#49){++++}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
blk_alloc_queue+0x610/0x790 block/blk-core.c:504
blk_mq_alloc_queue+0x174/0x290 block/blk-mq.c:4420
__blk_mq_alloc_disk+0x29/0x120 block/blk-mq.c:4467
nbd_dev_add+0x491/0xb10 drivers/block/nbd.c:1996
nbd_init+0x2c5/0x2e0 drivers/block/nbd.c:2743
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #1 (fs_reclaim){+.+.}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
__fs_reclaim_acquire mm/page_alloc.c:4375 [inline]
fs_reclaim_acquire+0xc4/0x100 mm/page_alloc.c:4389
might_alloc include/linux/sched/mm.h:314 [inline]
slab_pre_alloc_hook mm/slub.c:4539 [inline]
slab_alloc_node mm/slub.c:4899 [inline]
kmem_cache_alloc_noprof+0x63/0x6a0 mm/slub.c:4933
__kernfs_iattrs+0x126/0x450 fs/kernfs/inode.c:36
kernfs_iattrs fs/kernfs/inode.c:60 [inline]
__kernfs_setattr+0x4d/0x3c0 fs/kernfs/inode.c:73
kernfs_iop_setattr+0xda/0x130 fs/kernfs/inode.c:127
notify_change+0xb25/0x1330 fs/attr.c:556
do_truncate+0x1df/0x240 fs/open.c:68
handle_truncate fs/namei.c:4300 [inline]
do_open fs/namei.c:4841 [inline]
path_openat+0x1e6d/0x2440 fs/namei.c:5000
do_file_open+0x20e/0x430 fs/namei.c:5029
do_sys_openat2+0x10f/0x1e0 fs/open.c:1417
do_sys_open fs/open.c:1423 [inline]
__do_sys_openat fs/open.c:1439 [inline]
__se_sys_openat fs/open.c:1434 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1434
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&root->kernfs_iattr_rwsem){++++}-{4:4}:
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3181
check_prevs_add kernel/locking/lockdep.c:3300 [inline]
validate_chain kernel/locking/lockdep.c:3924 [inline]
__lock_acquire+0x1492/0x1ec0 kernel/locking/lockdep.c:5253
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
kernfs_add_one+0x1e7/0xaa0 fs/kernfs/dir.c:844
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
sysfs_create_dir_ns+0x13a/0x2b0 fs/sysfs/dir.c:59
create_dir lib/kobject.c:73 [inline]
kobject_add_internal+0x2c8/0x930 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_add+0x16a/0x1e0 lib/kobject.c:426
device_add+0x294/0x1970 drivers/base/core.c:3699
hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:3065
uhid_device_add_worker+0x3a/0x70 drivers/hid/uhid.c:73
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
&root->kernfs_iattr_rwsem --> cpuhp_state_mutex --> &root->kernfs_rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&root->kernfs_rwsem);
lock(cpuhp_state_mutex);
lock(&root->kernfs_rwsem);
lock(&root->kernfs_iattr_rwsem);
*** DEADLOCK ***
locks held by kworker/3:0/34: 3, last CPU#3:
#0: ffff88801c0aa940 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1466/0x1b10 kernel/workqueue.c:3362
#1: ffffc900006dfd08 ((work_completion)(&uhid->worker)){+.+.}-{0:0}, at: process_one_work+0xa2c/0x1b10 kernel/workqueue.c:3363
#2: ffff88801d6a5980 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
stack backtrace:
CPU: 3 UID: 0 PID: 34 Comm: kworker/3:0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: events uhid_device_add_worker
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_circular_bug.cold+0x178/0x1be kernel/locking/lockdep.c:2059
check_noncircular+0x146/0x160 kernel/locking/lockdep.c:2191
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3181
check_prevs_add kernel/locking/lockdep.c:3300 [inline]
validate_chain kernel/locking/lockdep.c:3924 [inline]
__lock_acquire+0x1492/0x1ec0 kernel/locking/lockdep.c:5253
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
kernfs_add_one+0x1e7/0xaa0 fs/kernfs/dir.c:844
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
sysfs_create_dir_ns+0x13a/0x2b0 fs/sysfs/dir.c:59
create_dir lib/kobject.c:73 [inline]
kobject_add_internal+0x2c8/0x930 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_add+0x16a/0x1e0 lib/kobject.c:426
device_add+0x294/0x1970 drivers/base/core.c:3699
hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:3065
uhid_device_add_worker+0x3a/0x70 drivers/hid/uhid.c:73
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
input: shield Haptics as /devices/virtual/input/input5
shield 0003:0955:7214.0002: Registered Thunderstrike controller
shield 0003:0955:7214.0002: : USB HID v0.00 Gamepad [shield] on
---
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
2026-08-26 19:33 ` syzbot
@ 2026-08-26 22:49 ` Hillf Danton
2026-08-27 3:01 ` [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler syzbot
2026-08-27 6:03 ` [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2) Hillf Danton
2026-08-27 8:15 ` Hillf Danton
2 siblings, 1 reply; 28+ messages in thread
From: Hillf Danton @ 2026-08-26 22:49 UTC (permalink / raw)
To: syzbot
Cc: linux-kernel, syzkaller-bugs, syzbot+2d770620059281e225a4, Eric Dumazet
> Date: Wed, 26 Aug 2026 12:33:31 -0700 [thread overview]
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: 818bebeb63dd drm/xe: Don't hand out the flat CCS storage a..
> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> console output: https://syzkaller.appspot.com/x/log.txt?x=10059625580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=ccca94d2c01b9e78
> dashboard link: https://syzkaller.appspot.com/bug?extid=dd764a450d93885d847f
> compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13de8d49580000
#syz test
syzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in
hlock_class() due to an invalid class_idx:
WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]
RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline]
RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203
Call Trace:
<IRQ>
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173
tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291
tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325
...
When a lock class is zapped (e.g. during module unload or key
unregistration), zap_class() clears the class's bit in
lock_classes_in_use and removes it from the class hash table.
However, existing lockdep_map instances embedded in data structures
may still retain a pointer to the zapped class in their class_cache[]
array.
When __lock_acquire() subsequently runs on such a lock, it finds
lock->class_cache[subclass] != NULL, skipping register_lock_class() and
assigning hlock->class_idx to the index of the zapped class. When
check_wait_context() or hlock_class() inspects the held_lock, it finds
!test_bit(class_idx, lock_classes_in_use) and warns. Furthermore, if
the zapped slot is subsequently re-allocated to an unrelated lock key,
the stale class_cache entry would erroneously match the unrelated class
(ABA issue).
Add lock_class_cache_is_valid() to validate that the cached class is
within lock_classes bounds, still allocated in lock_classes_in_use
(using uninstrumented arch_test_bit() in __always_inline context so it
is safe in noinstr contexts like match_held_lock()), and that class->key
matches the expected subkey (taking lockdep_set_subclass() overrides into
account). Also use READ_ONCE()/WRITE_ONCE() when accessing class_cache[].
If the entry is invalid or stale, fall back to register_lock_class() /
look_up_lock_class().
Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use")
Reported-by: syzbot+2d770620059281e225a4@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a8c66dc.4d75e56a.c9a88.0050.GAE@google.com/T/#u
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
kernel/locking/lockdep.c | 50 +++++++++++++++++++++++++++++++++-------
1 file changed, 42 insertions(+), 8 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 25d77d4a1061..763f79806bd8 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -963,6 +963,34 @@ look_up_lock_class(const struct lockdep_map *lock, unsigned int subclass)
return NULL;
}
+static __always_inline bool lock_class_cache_is_valid(const struct lockdep_map *lock,
+ const struct lock_class *class,
+ unsigned int subclass)
+{
+ unsigned int class_subclass;
+
+ if (!class)
+ return false;
+
+ if (unlikely(class < lock_classes || class >= lock_classes + MAX_LOCKDEP_KEYS))
+ return false;
+
+ if (unlikely(!arch_test_bit(class - lock_classes, lock_classes_in_use)))
+ return false;
+
+ if (unlikely(!lock->key))
+ return false;
+
+ class_subclass = subclass ? subclass : class->subclass;
+ if (unlikely(class_subclass >= MAX_LOCKDEP_SUBCLASSES))
+ return false;
+
+ if (unlikely(READ_ONCE(class->key) != lock->key->subkeys + class_subclass))
+ return false;
+
+ return true;
+}
+
/*
* Static locks do not have their class-keys yet - for them the key is
* the lock object itself. If the lock is in the per cpu area, the
@@ -1395,9 +1423,9 @@ register_lock_class(struct lockdep_map *lock, unsigned int subclass, int force)
out_set_class_cache:
if (!subclass || force)
- lock->class_cache[0] = class;
+ WRITE_ONCE(lock->class_cache[0], class);
else if (subclass < NR_LOCKDEP_CACHING_CLASSES)
- lock->class_cache[subclass] = class;
+ WRITE_ONCE(lock->class_cache[subclass], class);
/*
* Hash collision, did we smoke some? We found a class with a matching
@@ -4957,7 +4985,7 @@ void lockdep_init_map_type(struct lockdep_map *lock, const char *name,
int i;
for (i = 0; i < NR_LOCKDEP_CACHING_CLASSES; i++)
- lock->class_cache[i] = NULL;
+ WRITE_ONCE(lock->class_cache[i], NULL);
#ifdef CONFIG_LOCK_STAT
lock->cpu = raw_smp_processor_id();
@@ -5022,12 +5050,15 @@ EXPORT_SYMBOL_GPL(__lockdep_no_track__);
void lockdep_set_lock_cmp_fn(struct lockdep_map *lock, lock_cmp_fn cmp_fn,
lock_print_fn print_fn)
{
- struct lock_class *class = lock->class_cache[0];
+ struct lock_class *class = READ_ONCE(lock->class_cache[0]);
unsigned long flags;
raw_local_irq_save(flags);
lockdep_recursion_inc();
+ if (!lock_class_cache_is_valid(lock, class, 0))
+ class = NULL;
+
if (!class)
class = register_lock_class(lock, 0, 0);
@@ -5119,8 +5150,11 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
if (DEBUG_LOCKS_WARN_ON(subclass >= MAX_LOCKDEP_SUBCLASSES))
return 0;
- if (subclass < NR_LOCKDEP_CACHING_CLASSES)
- class = lock->class_cache[subclass];
+ if (subclass < NR_LOCKDEP_CACHING_CLASSES) {
+ class = READ_ONCE(lock->class_cache[subclass]);
+ if (!lock_class_cache_is_valid(lock, class, subclass))
+ class = NULL;
+ }
/*
* Not cached?
*/
@@ -5323,9 +5357,9 @@ static noinstr int match_held_lock(const struct held_lock *hlock,
return 1;
if (hlock->references) {
- const struct lock_class *class = lock->class_cache[0];
+ const struct lock_class *class = READ_ONCE(lock->class_cache[0]);
- if (!class)
+ if (!lock_class_cache_is_valid(lock, class, 0))
class = look_up_lock_class(lock, 0);
/*
base-commit: 0a0d1d55dad570724bf8c7ea83409639cfb4be9b
--
2.55.0.766.g2966f0265a-goog
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-26 22:49 ` Hillf Danton
@ 2026-08-27 3:01 ` syzbot
0 siblings, 0 replies; 28+ messages in thread
From: syzbot @ 2026-08-27 3:01 UTC (permalink / raw)
To: edumazet, hdanton, linux-kernel, syzkaller-bugs
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in tcp_tsq_handler
------------[ cut here ]------------
!lockdep_sock_is_held(sk) && debug_locks
WARNING: ./include/net/sock.h:1799 at sock_owned_by_me include/net/sock.h:1799 [inline], CPU#0: kworker/0:0/9
WARNING: ./include/net/sock.h:1799 at sock_owned_by_user include/net/sock.h:1812 [inline], CPU#0: kworker/0:0/9
WARNING: ./include/net/sock.h:1799 at tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292, CPU#0: kworker/0:0/9
Modules linked in:
CPU: 0 UID: 0 PID: 9 Comm: kworker/0:0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
RIP: 0010:sock_owned_by_me include/net/sock.h:1799 [inline]
RIP: 0010:sock_owned_by_user include/net/sock.h:1812 [inline]
RIP: 0010:tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292
Code: 00 97 96 01 e8 fb 15 79 f7 be 02 00 00 00 eb 0a e8 ef 15 79 f7 be 01 00 00 00 4c 89 ff e8 a2 7f 8e fa eb d0 e8 db 15 79 f7 90 <0f> 0b 90 e9 fd fe ff ff 44 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 07
RSP: 0018:ffffc90000007bb0 EFLAGS: 00010246
RAX: ffffffff8a4e9ad5 RBX: ffff88805ab935d0 RCX: ffff88801defddc0
RDX: 0000000000000100 RSI: 0000000000000100 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000100 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff52000000f64 R12: dffffc0000000000
R13: ffffc90000007c20 R14: ffff88805ab93400 R15: ffff88805ab93400
FS: 0000000000000000(0000) GS:ffff888124ce0000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007ffe3b037048 CR3: 000000000eb48000 CR4: 00000000003526f0
Call Trace:
<IRQ>
tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325
process_one_work kernel/workqueue.c:3387 [inline]
process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
bh_worker+0x451/0x870 kernel/workqueue.c:3773
tasklet_action+0xc/0x70 kernel/softirq.c:997
handle_softirqs+0x226/0x860 kernel/softirq.c:645
do_softirq+0x77/0xd0 kernel/softirq.c:546
</IRQ>
<TASK>
__local_bh_enable_ip+0x100/0x140 kernel/softirq.c:473
wg_socket_send_skb_to_peer+0x16b/0x1d0 drivers/net/wireguard/socket.c:183
wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline]
wg_packet_tx_worker+0x1c8/0x7e0 drivers/net/wireguard/send.c:276
process_one_work kernel/workqueue.c:3387 [inline]
process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551
kthread+0x38b/0x480 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Tested on:
commit: 73e3f071 Merge tag 'nfs-for-7.3-1' of git://git.linux-..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=15425625580000
kernel config: https://syzkaller.appspot.com/x/.config?x=22381429a4c2735a
dashboard link: https://syzkaller.appspot.com/bug?extid=2d770620059281e225a4
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=10bb399e580000
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
2026-08-26 19:33 ` syzbot
2026-08-26 22:49 ` Hillf Danton
@ 2026-08-27 6:03 ` Hillf Danton
2026-08-27 6:21 ` syzbot
2026-08-27 8:15 ` Hillf Danton
2 siblings, 1 reply; 28+ messages in thread
From: Hillf Danton @ 2026-08-27 6:03 UTC (permalink / raw)
To: syzbot; +Cc: linux-kernel, syzkaller-bugs
> Date: Wed, 26 Aug 2026 12:33:31 -0700 [thread overview]
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: 818bebeb63dd drm/xe: Don't hand out the flat CCS storage a..
> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> console output: https://syzkaller.appspot.com/x/log.txt?x=10059625580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=ccca94d2c01b9e78
> dashboard link: https://syzkaller.appspot.com/bug?extid=dd764a450d93885d847f
> compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13de8d49580000
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 818bebeb63dd
--- x/kernel/locking/lockdep.c
+++ y/kernel/locking/lockdep.c
@@ -947,6 +947,34 @@ look_up_lock_class(const struct lockdep_
return NULL;
}
+static __always_inline bool lock_class_cache_is_valid(const struct lockdep_map *lock,
+ const struct lock_class *class,
+ unsigned int subclass)
+{
+ unsigned int class_subclass;
+
+ if (!class)
+ return false;
+
+ if (unlikely(class < lock_classes || class >= lock_classes + MAX_LOCKDEP_KEYS))
+ return false;
+
+ if (unlikely(!arch_test_bit(class - lock_classes, lock_classes_in_use)))
+ return false;
+
+ if (unlikely(!lock->key))
+ return false;
+
+ class_subclass = subclass ? subclass : class->subclass;
+ if (unlikely(class_subclass >= MAX_LOCKDEP_SUBCLASSES))
+ return false;
+
+ if (unlikely(READ_ONCE(class->key) != lock->key->subkeys + class_subclass))
+ return false;
+
+ return true;
+}
+
/*
* Static locks do not have their class-keys yet - for them the key is
* the lock object itself. If the lock is in the per cpu area, the
@@ -1379,9 +1407,9 @@ out_unlock_set:
out_set_class_cache:
if (!subclass || force)
- lock->class_cache[0] = class;
+ WRITE_ONCE(lock->class_cache[0], class);
else if (subclass < NR_LOCKDEP_CACHING_CLASSES)
- lock->class_cache[subclass] = class;
+ WRITE_ONCE(lock->class_cache[subclass], class);
/*
* Hash collision, did we smoke some? We found a class with a matching
@@ -4941,7 +4969,7 @@ void lockdep_init_map_type(struct lockde
int i;
for (i = 0; i < NR_LOCKDEP_CACHING_CLASSES; i++)
- lock->class_cache[i] = NULL;
+ WRITE_ONCE(lock->class_cache[i], NULL);
#ifdef CONFIG_LOCK_STAT
lock->cpu = raw_smp_processor_id();
@@ -5006,12 +5034,15 @@ EXPORT_SYMBOL_GPL(__lockdep_no_track__);
void lockdep_set_lock_cmp_fn(struct lockdep_map *lock, lock_cmp_fn cmp_fn,
lock_print_fn print_fn)
{
- struct lock_class *class = lock->class_cache[0];
+ struct lock_class *class = READ_ONCE(lock->class_cache[0]);
unsigned long flags;
raw_local_irq_save(flags);
lockdep_recursion_inc();
+ if (!lock_class_cache_is_valid(lock, class, 0))
+ class = NULL;
+
if (!class)
class = register_lock_class(lock, 0, 0);
@@ -5103,8 +5134,11 @@ static int __lock_acquire(struct lockdep
if (DEBUG_LOCKS_WARN_ON(subclass >= MAX_LOCKDEP_SUBCLASSES))
return 0;
- if (subclass < NR_LOCKDEP_CACHING_CLASSES)
- class = lock->class_cache[subclass];
+ if (subclass < NR_LOCKDEP_CACHING_CLASSES) {
+ class = READ_ONCE(lock->class_cache[subclass]);
+ if (!lock_class_cache_is_valid(lock, class, subclass))
+ class = NULL;
+ }
/*
* Not cached?
*/
@@ -5307,9 +5341,9 @@ static noinstr int match_held_lock(const
return 1;
if (hlock->references) {
- const struct lock_class *class = lock->class_cache[0];
+ const struct lock_class *class = READ_ONCE(lock->class_cache[0]);
- if (!class)
+ if (!lock_class_cache_is_valid(lock, class, 0))
class = look_up_lock_class(lock, 0);
/*
--- x/lib/once.c
+++ y/lib/once.c
@@ -93,6 +93,6 @@ void __do_once_sleepable_done(bool *done
{
*done = true;
mutex_unlock(&once_mutex);
- static_branch_disable(once_key);
+ once_disable_jump(once_key, mod);
}
EXPORT_SYMBOL(__do_once_sleepable_done);
--
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
2026-08-27 6:03 ` [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2) Hillf Danton
@ 2026-08-27 6:21 ` syzbot
0 siblings, 0 replies; 28+ messages in thread
From: syzbot @ 2026-08-27 6:21 UTC (permalink / raw)
To: hdanton, linux-kernel, syzkaller-bugs
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
possible deadlock in kernfs_link_sibling
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
kworker/0:4/5891 is trying to acquire lock:
ffff88801d6a5a10 (&root->kernfs_iattr_rwsem){++++}-{4:4}, at: kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
but task is already holding lock:
ffff88801d6a5980 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #9 (&root->kernfs_rwsem){++++}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
internal_create_group+0x36f/0xfb0 fs/sysfs/group.c:176
cpuhp_invoke_callback+0x3b4/0x9a0 kernel/cpu.c:194
cpuhp_issue_call+0x1b8/0x970 kernel/cpu.c:2354
__cpuhp_setup_state_cpuslocked+0x431/0x880 kernel/cpu.c:2507
__cpuhp_setup_state+0xf7/0x2f0 kernel/cpu.c:2536
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #8 (cpuhp_state_mutex){+.+.}-{4:4}:
-> #7 (cpu_hotplug_lock){++++}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
percpu_down_read_internal include/linux/percpu-rwsem.h:53 [inline]
percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
cpus_read_lock+0x42/0x170 kernel/cpu.c:490
static_key_slow_inc+0x12/0x30 kernel/jump_label.c:190
nbd_genl_reconnect_sock_cb+0x39f/0x990 drivers/block/nbd.c:1377
nbd_genl_foreach_sock+0x2ab/0x3e0 drivers/block/nbd.c:2152
nbd_genl_reconfigure+0x861/0xde0 drivers/block/nbd.c:2477
genl_family_rcv_msg_doit+0x214/0x300 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x560/0x800 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2556
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec net/socket.c:800 [inline]
__sock_sendmsg net/socket.c:815 [inline]
__sys_sendto+0x48b/0x4e0 net/socket.c:2281
__do_sys_sendto net/socket.c:2288 [inline]
__se_sys_sendto net/socket.c:2284 [inline]
__x64_sys_sendto+0xe0/0x1c0 net/socket.c:2284
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #6 (&nsock->tx_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
nbd_handle_cmd drivers/block/nbd.c:1143 [inline]
nbd_queue_rq+0x42d/0xfa0 drivers/block/nbd.c:1207
blk_mq_dispatch_rq_list+0x428/0x1e60 block/blk-mq.c:2117
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xcea/0x1620 block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xd7/0x1c0 block/blk-mq-sched.c:329
blk_mq_run_work_fn+0x135/0x380 block/blk-mq.c:2531
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #5 (&cmd->lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
nbd_queue_rq+0xba/0xfa0 drivers/block/nbd.c:1199
blk_mq_dispatch_rq_list+0x428/0x1e60 block/blk-mq.c:2117
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xcea/0x1620 block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xd7/0x1c0 block/blk-mq-sched.c:329
blk_mq_run_work_fn+0x135/0x380 block/blk-mq.c:2531
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #4 (set->srcu){.+.+}-{0:0}:
lock_sync kernel/locking/lockdep.c:5968 [inline]
lock_sync+0x9d/0x110 kernel/locking/lockdep.c:5956
srcu_lock_sync include/linux/srcu.h:199 [inline]
__synchronize_srcu+0xa2/0x300 kernel/rcu/srcutree.c:1481
blk_mq_wait_quiesce_done block/blk-mq.c:284 [inline]
blk_mq_wait_quiesce_done block/blk-mq.c:281 [inline]
blk_mq_quiesce_queue block/blk-mq.c:304 [inline]
blk_mq_quiesce_queue+0x149/0x1c0 block/blk-mq.c:299
elevator_switch+0x17b/0x7e0 block/elevator.c:576
elevator_change+0x352/0x530 block/elevator.c:681
elevator_set_default+0x29e/0x360 block/elevator.c:754
blk_register_queue+0x48e/0x630 block/blk-sysfs.c:992
__add_disk+0x73f/0xe40 block/genhd.c:524
add_disk_fwnode+0x118/0x480 block/genhd.c:593
add_disk include/linux/blkdev.h:798 [inline]
nbd_dev_add+0x779/0xb10 drivers/block/nbd.c:2026
nbd_init+0x2c5/0x2e0 drivers/block/nbd.c:2743
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #3 (&q->elevator_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
elevator_change+0x1bc/0x530 block/elevator.c:679
elevator_set_none+0x92/0xf0 block/elevator.c:769
blk_mq_elv_switch_none block/blk-mq.c:5102 [inline]
__blk_mq_update_nr_hw_queues block/blk-mq.c:5147 [inline]
blk_mq_update_nr_hw_queues+0x4c1/0x15f0 block/blk-mq.c:5212
nbd_start_device+0x1a6/0xbd0 drivers/block/nbd.c:1530
nbd_genl_connect+0xfc2/0x1760 drivers/block/nbd.c:2310
genl_family_rcv_msg_doit+0x214/0x300 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x560/0x800 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2556
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec net/socket.c:800 [inline]
__sock_sendmsg net/socket.c:815 [inline]
__sys_sendto+0x48b/0x4e0 net/socket.c:2281
__do_sys_sendto net/socket.c:2288 [inline]
__se_sys_sendto net/socket.c:2284 [inline]
__x64_sys_sendto+0xe0/0x1c0 net/socket.c:2284
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #2 (&q->q_usage_counter(io)#49){++++}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
blk_alloc_queue+0x610/0x790 block/blk-core.c:504
blk_mq_alloc_queue+0x174/0x290 block/blk-mq.c:4420
__blk_mq_alloc_disk+0x29/0x120 block/blk-mq.c:4467
nbd_dev_add+0x491/0xb10 drivers/block/nbd.c:1996
nbd_init+0x2c5/0x2e0 drivers/block/nbd.c:2743
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #1 (fs_reclaim){+.+.}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
__fs_reclaim_acquire mm/page_alloc.c:4375 [inline]
fs_reclaim_acquire+0xc4/0x100 mm/page_alloc.c:4389
might_alloc include/linux/sched/mm.h:314 [inline]
slab_pre_alloc_hook mm/slub.c:4539 [inline]
slab_alloc_node mm/slub.c:4899 [inline]
kmem_cache_alloc_noprof+0x63/0x6a0 mm/slub.c:4933
__kernfs_iattrs+0x126/0x450 fs/kernfs/inode.c:36
kernfs_iattrs fs/kernfs/inode.c:60 [inline]
__kernfs_setattr+0x4d/0x3c0 fs/kernfs/inode.c:73
kernfs_iop_setattr+0xda/0x130 fs/kernfs/inode.c:127
notify_change+0xb25/0x1330 fs/attr.c:556
do_truncate+0x1df/0x240 fs/open.c:68
handle_truncate fs/namei.c:4300 [inline]
do_open fs/namei.c:4841 [inline]
path_openat+0x1e6d/0x2440 fs/namei.c:5000
do_file_open+0x20e/0x430 fs/namei.c:5029
do_sys_openat2+0x10f/0x1e0 fs/open.c:1417
do_sys_open fs/open.c:1423 [inline]
__do_sys_openat fs/open.c:1439 [inline]
__se_sys_openat fs/open.c:1434 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1434
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&root->kernfs_iattr_rwsem){++++}-{4:4}:
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3209
check_prevs_add kernel/locking/lockdep.c:3328 [inline]
validate_chain kernel/locking/lockdep.c:3952 [inline]
__lock_acquire+0x1508/0x1f20 kernel/locking/lockdep.c:5287
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
kernfs_add_one+0x1e7/0xaa0 fs/kernfs/dir.c:844
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
sysfs_create_dir_ns+0x13a/0x2b0 fs/sysfs/dir.c:59
create_dir lib/kobject.c:73 [inline]
kobject_add_internal+0x2c8/0x930 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_add+0x16a/0x1e0 lib/kobject.c:426
device_add+0x294/0x1970 drivers/base/core.c:3699
hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:3065
uhid_device_add_worker+0x3a/0x70 drivers/hid/uhid.c:73
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
&root->kernfs_iattr_rwsem --> cpuhp_state_mutex --> &root->kernfs_rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&root->kernfs_rwsem);
lock(cpuhp_state_mutex);
lock(&root->kernfs_rwsem);
lock(&root->kernfs_iattr_rwsem);
*** DEADLOCK ***
locks held by kworker/0:4/5891: 3, last CPU#0:
#0: ffff88801c0aa940 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1466/0x1b10 kernel/workqueue.c:3362
#1: ffffc90003487d08 ((work_completion)(&uhid->worker)){+.+.}-{0:0}, at: process_one_work+0xa2c/0x1b10 kernel/workqueue.c:3363
#2: ffff88801d6a5980 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
stack backtrace:
CPU: 0 UID: 0 PID: 5891 Comm: kworker/0:4 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: events uhid_device_add_worker
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_circular_bug.cold+0x178/0x1be kernel/locking/lockdep.c:2087
check_noncircular+0x146/0x160 kernel/locking/lockdep.c:2219
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3209
check_prevs_add kernel/locking/lockdep.c:3328 [inline]
validate_chain kernel/locking/lockdep.c:3952 [inline]
__lock_acquire+0x1508/0x1f20 kernel/locking/lockdep.c:5287
lock_acquire kernel/locking/lockdep.c:5920 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5877
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
kernfs_add_one+0x1e7/0xaa0 fs/kernfs/dir.c:844
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
sysfs_create_dir_ns+0x13a/0x2b0 fs/sysfs/dir.c:59
create_dir lib/kobject.c:73 [inline]
kobject_add_internal+0x2c8/0x930 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_add+0x16a/0x1e0 lib/kobject.c:426
device_add+0x294/0x1970 drivers/base/core.c:3699
hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:3065
uhid_device_add_worker+0x3a/0x70 drivers/hid/uhid.c:73
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
input: shield Haptics as /devices/virtual/input/input5
shield 0003:0955:7214.0002: Registered Thunderstrike controller
shield 0003:0955:7214.0002: : USB HID v0.00 Gamepad [shield] on
Tested on:
commit: 818bebeb drm/xe: Don't hand out the flat CCS storage a..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=159e6d49580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ccca94d2c01b9e78
dashboard link: https://syzkaller.appspot.com/bug?extid=dd764a450d93885d847f
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch: https://syzkaller.appspot.com/x/patch.diff?x=111eb415580000
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
2026-08-26 19:33 ` syzbot
2026-08-26 22:49 ` Hillf Danton
2026-08-27 6:03 ` [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2) Hillf Danton
@ 2026-08-27 8:15 ` Hillf Danton
2026-08-27 10:33 ` syzbot
2 siblings, 1 reply; 28+ messages in thread
From: Hillf Danton @ 2026-08-27 8:15 UTC (permalink / raw)
To: syzbot; +Cc: linux-kernel, syzkaller-bugs
> Date: Wed, 26 Aug 2026 12:33:31 -0700 [thread overview]
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit: 818bebeb63dd drm/xe: Don't hand out the flat CCS storage a..
> git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> console output: https://syzkaller.appspot.com/x/log.txt?x=10059625580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=ccca94d2c01b9e78
> dashboard link: https://syzkaller.appspot.com/bug?extid=dd764a450d93885d847f
> compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
> C reproducer: https://syzkaller.appspot.com/x/repro.c?x=13de8d49580000
#syz test: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 818bebeb63dd
--- x/lib/once.c
+++ y/lib/once.c
@@ -93,6 +93,6 @@ void __do_once_sleepable_done(bool *done
{
*done = true;
mutex_unlock(&once_mutex);
- static_branch_disable(once_key);
+ once_disable_jump(once_key, mod);
}
EXPORT_SYMBOL(__do_once_sleepable_done);
--
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
2026-08-27 8:15 ` Hillf Danton
@ 2026-08-27 10:33 ` syzbot
0 siblings, 0 replies; 28+ messages in thread
From: syzbot @ 2026-08-27 10:33 UTC (permalink / raw)
To: hdanton, linux-kernel, syzkaller-bugs
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
possible deadlock in kernfs_link_sibling
======================================================
WARNING: possible circular locking dependency detected
syzkaller #0 Not tainted
------------------------------------------------------
kworker/2:1/50 is trying to acquire lock:
ffff88801d6a5a10 (&root->kernfs_iattr_rwsem){++++}-{4:4}, at: kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
but task is already holding lock:
ffff88801d6a5980 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
which lock already depends on the new lock.
the existing dependency chain (in reverse order) is:
-> #9 (&root->kernfs_rwsem){++++}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
internal_create_group+0x36f/0xfb0 fs/sysfs/group.c:176
cpuhp_invoke_callback+0x3b4/0x9a0 kernel/cpu.c:194
cpuhp_issue_call+0x1b8/0x970 kernel/cpu.c:2354
__cpuhp_setup_state_cpuslocked+0x431/0x880 kernel/cpu.c:2507
__cpuhp_setup_state+0xf7/0x2f0 kernel/cpu.c:2536
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #8 (cpuhp_state_mutex){+.+.}-{4:4}:
-> #7 (cpu_hotplug_lock){++++}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
percpu_down_read_internal include/linux/percpu-rwsem.h:53 [inline]
percpu_down_read include/linux/percpu-rwsem.h:77 [inline]
cpus_read_lock+0x42/0x170 kernel/cpu.c:490
static_key_slow_inc+0x12/0x30 kernel/jump_label.c:190
nbd_genl_reconnect_sock_cb+0x39f/0x990 drivers/block/nbd.c:1377
nbd_genl_foreach_sock+0x2ab/0x3e0 drivers/block/nbd.c:2152
nbd_genl_reconfigure+0x861/0xde0 drivers/block/nbd.c:2477
genl_family_rcv_msg_doit+0x214/0x300 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x560/0x800 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2556
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec net/socket.c:800 [inline]
__sock_sendmsg net/socket.c:815 [inline]
__sys_sendto+0x48b/0x4e0 net/socket.c:2281
__do_sys_sendto net/socket.c:2288 [inline]
__se_sys_sendto net/socket.c:2284 [inline]
__x64_sys_sendto+0xe0/0x1c0 net/socket.c:2284
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #6 (&nsock->tx_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
nbd_handle_cmd drivers/block/nbd.c:1143 [inline]
nbd_queue_rq+0x42d/0xfa0 drivers/block/nbd.c:1207
blk_mq_dispatch_rq_list+0x428/0x1e60 block/blk-mq.c:2117
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xcea/0x1620 block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xd7/0x1c0 block/blk-mq-sched.c:329
blk_mq_run_work_fn+0x135/0x380 block/blk-mq.c:2531
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #5 (&cmd->lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
nbd_queue_rq+0xba/0xfa0 drivers/block/nbd.c:1199
blk_mq_dispatch_rq_list+0x428/0x1e60 block/blk-mq.c:2117
__blk_mq_do_dispatch_sched block/blk-mq-sched.c:168 [inline]
blk_mq_do_dispatch_sched block/blk-mq-sched.c:182 [inline]
__blk_mq_sched_dispatch_requests+0xcea/0x1620 block/blk-mq-sched.c:307
blk_mq_sched_dispatch_requests+0xd7/0x1c0 block/blk-mq-sched.c:329
blk_mq_run_work_fn+0x135/0x380 block/blk-mq.c:2531
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #4 (set->srcu){.+.+}-{0:0}:
lock_sync kernel/locking/lockdep.c:5934 [inline]
lock_sync+0x9d/0x110 kernel/locking/lockdep.c:5922
srcu_lock_sync include/linux/srcu.h:199 [inline]
__synchronize_srcu+0xa2/0x300 kernel/rcu/srcutree.c:1481
blk_mq_wait_quiesce_done block/blk-mq.c:284 [inline]
blk_mq_wait_quiesce_done block/blk-mq.c:281 [inline]
blk_mq_quiesce_queue block/blk-mq.c:304 [inline]
blk_mq_quiesce_queue+0x149/0x1c0 block/blk-mq.c:299
elevator_switch+0x17b/0x7e0 block/elevator.c:576
elevator_change+0x352/0x530 block/elevator.c:681
elevator_set_default+0x29e/0x360 block/elevator.c:754
blk_register_queue+0x48e/0x630 block/blk-sysfs.c:992
__add_disk+0x73f/0xe40 block/genhd.c:524
add_disk_fwnode+0x118/0x480 block/genhd.c:593
add_disk include/linux/blkdev.h:798 [inline]
nbd_dev_add+0x779/0xb10 drivers/block/nbd.c:2026
nbd_init+0x2c5/0x2e0 drivers/block/nbd.c:2743
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #3 (&q->elevator_lock){+.+.}-{4:4}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
__mutex_lock_common kernel/locking/mutex.c:646 [inline]
__mutex_lock+0x1a4/0x1bc0 kernel/locking/mutex.c:821
elevator_change+0x1bc/0x530 block/elevator.c:679
elevator_set_none+0x92/0xf0 block/elevator.c:769
blk_mq_elv_switch_none block/blk-mq.c:5102 [inline]
__blk_mq_update_nr_hw_queues block/blk-mq.c:5147 [inline]
blk_mq_update_nr_hw_queues+0x4c1/0x15f0 block/blk-mq.c:5212
nbd_start_device+0x1a6/0xbd0 drivers/block/nbd.c:1530
nbd_genl_connect+0xfc2/0x1760 drivers/block/nbd.c:2310
genl_family_rcv_msg_doit+0x214/0x300 net/netlink/genetlink.c:1114
genl_family_rcv_msg net/netlink/genetlink.c:1194 [inline]
genl_rcv_msg+0x560/0x800 net/netlink/genetlink.c:1209
netlink_rcv_skb+0x159/0x420 net/netlink/af_netlink.c:2556
genl_rcv+0x28/0x40 net/netlink/genetlink.c:1218
netlink_unicast_kernel net/netlink/af_netlink.c:1319 [inline]
netlink_unicast+0x585/0x850 net/netlink/af_netlink.c:1345
netlink_sendmsg+0x8b0/0xda0 net/netlink/af_netlink.c:1900
sock_sendmsg_nosec net/socket.c:800 [inline]
__sock_sendmsg net/socket.c:815 [inline]
__sys_sendto+0x48b/0x4e0 net/socket.c:2281
__do_sys_sendto net/socket.c:2288 [inline]
__se_sys_sendto net/socket.c:2284 [inline]
__x64_sys_sendto+0xe0/0x1c0 net/socket.c:2284
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #2 (&q->q_usage_counter(io)#49){++++}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
blk_alloc_queue+0x610/0x790 block/blk-core.c:504
blk_mq_alloc_queue+0x174/0x290 block/blk-mq.c:4420
__blk_mq_alloc_disk+0x29/0x120 block/blk-mq.c:4467
nbd_dev_add+0x491/0xb10 drivers/block/nbd.c:1996
nbd_init+0x2c5/0x2e0 drivers/block/nbd.c:2743
do_one_initcall+0x11c/0x6f0 init/main.c:1353
do_initcall_level init/main.c:1415 [inline]
do_initcalls init/main.c:1431 [inline]
do_basic_setup init/main.c:1451 [inline]
kernel_init_freeable+0x6ea/0x7b0 init/main.c:1666
kernel_init+0x21/0x1e0 init/main.c:1556
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
-> #1 (fs_reclaim){+.+.}-{0:0}:
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
__fs_reclaim_acquire mm/page_alloc.c:4375 [inline]
fs_reclaim_acquire+0xc4/0x100 mm/page_alloc.c:4389
might_alloc include/linux/sched/mm.h:314 [inline]
slab_pre_alloc_hook mm/slub.c:4539 [inline]
slab_alloc_node mm/slub.c:4899 [inline]
kmem_cache_alloc_noprof+0x63/0x6a0 mm/slub.c:4933
__kernfs_iattrs+0x126/0x450 fs/kernfs/inode.c:36
kernfs_iattrs fs/kernfs/inode.c:60 [inline]
__kernfs_setattr+0x4d/0x3c0 fs/kernfs/inode.c:73
kernfs_iop_setattr+0xda/0x130 fs/kernfs/inode.c:127
notify_change+0xb25/0x1330 fs/attr.c:556
do_truncate+0x1df/0x240 fs/open.c:68
handle_truncate fs/namei.c:4300 [inline]
do_open fs/namei.c:4841 [inline]
path_openat+0x1e6d/0x2440 fs/namei.c:5000
do_file_open+0x20e/0x430 fs/namei.c:5029
do_sys_openat2+0x10f/0x1e0 fs/open.c:1417
do_sys_open fs/open.c:1423 [inline]
__do_sys_openat fs/open.c:1439 [inline]
__se_sys_openat fs/open.c:1434 [inline]
__x64_sys_openat+0x12d/0x210 fs/open.c:1434
do_syscall_x64 arch/x86/entry/syscall_64.c:61 [inline]
do_syscall_64+0x123/0x790 arch/x86/entry/syscall_64.c:84
entry_SYSCALL_64_after_hwframe+0x77/0x7f
-> #0 (&root->kernfs_iattr_rwsem){++++}-{4:4}:
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3181
check_prevs_add kernel/locking/lockdep.c:3300 [inline]
validate_chain kernel/locking/lockdep.c:3924 [inline]
__lock_acquire+0x1492/0x1ec0 kernel/locking/lockdep.c:5253
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
kernfs_add_one+0x1e7/0xaa0 fs/kernfs/dir.c:844
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
sysfs_create_dir_ns+0x13a/0x2b0 fs/sysfs/dir.c:59
create_dir lib/kobject.c:73 [inline]
kobject_add_internal+0x2c8/0x930 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_add+0x16a/0x1e0 lib/kobject.c:426
device_add+0x294/0x1970 drivers/base/core.c:3699
hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:3065
uhid_device_add_worker+0x3a/0x70 drivers/hid/uhid.c:73
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
other info that might help us debug this:
Chain exists of:
&root->kernfs_iattr_rwsem --> cpuhp_state_mutex --> &root->kernfs_rwsem
Possible unsafe locking scenario:
CPU0 CPU1
---- ----
lock(&root->kernfs_rwsem);
lock(cpuhp_state_mutex);
lock(&root->kernfs_rwsem);
lock(&root->kernfs_iattr_rwsem);
*** DEADLOCK ***
locks held by kworker/2:1/50: 3, last CPU#2:
#0: ffff88801c0aa940 ((wq_completion)events){+.+.}-{0:0}, at: process_one_work+0x1466/0x1b10 kernel/workqueue.c:3362
#1: ffffc90000a3fd08 ((work_completion)(&uhid->worker)){+.+.}-{0:0}, at: process_one_work+0xa2c/0x1b10 kernel/workqueue.c:3363
#2: ffff88801d6a5980 (&root->kernfs_rwsem){++++}-{4:4}, at: kernfs_add_one+0x38/0xaa0 fs/kernfs/dir.c:825
stack backtrace:
CPU: 2 UID: 0 PID: 50 Comm: kworker/2:1 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS 1.16.3-debian-1.16.3-2 04/01/2014
Workqueue: events uhid_device_add_worker
Call Trace:
<TASK>
__dump_stack lib/dump_stack.c:94 [inline]
dump_stack_lvl+0x100/0x190 lib/dump_stack.c:120
print_circular_bug.cold+0x178/0x1be kernel/locking/lockdep.c:2059
check_noncircular+0x146/0x160 kernel/locking/lockdep.c:2191
check_prev_add+0xeb/0xe60 kernel/locking/lockdep.c:3181
check_prevs_add kernel/locking/lockdep.c:3300 [inline]
validate_chain kernel/locking/lockdep.c:3924 [inline]
__lock_acquire+0x1492/0x1ec0 kernel/locking/lockdep.c:5253
lock_acquire kernel/locking/lockdep.c:5886 [inline]
lock_acquire+0x1b9/0x370 kernel/locking/lockdep.c:5843
down_write+0x8b/0x1f0 kernel/locking/rwsem.c:1631
kernfs_link_sibling+0x555/0x850 fs/kernfs/dir.c:411
kernfs_add_one+0x1e7/0xaa0 fs/kernfs/dir.c:844
kernfs_create_dir_ns+0x157/0x2b0 fs/kernfs/dir.c:1130
sysfs_create_dir_ns+0x13a/0x2b0 fs/sysfs/dir.c:59
create_dir lib/kobject.c:73 [inline]
kobject_add_internal+0x2c8/0x930 lib/kobject.c:240
kobject_add_varg lib/kobject.c:374 [inline]
kobject_add+0x16a/0x1e0 lib/kobject.c:426
device_add+0x294/0x1970 drivers/base/core.c:3699
hid_add_device+0x2bf/0x440 drivers/hid/hid-core.c:3065
uhid_device_add_worker+0x3a/0x70 drivers/hid/uhid.c:73
process_one_work+0xac7/0x1b10 kernel/workqueue.c:3387
process_scheduled_works kernel/workqueue.c:3470 [inline]
worker_thread+0x5ef/0xe50 kernel/workqueue.c:3551
kthread+0x373/0x450 kernel/kthread.c:436
ret_from_fork+0x730/0xd60 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
input: shield Haptics as /devices/virtual/input/input5
shield 0003:0955:7214.0002: Registered Thunderstrike controller
shield 0003:0955:7214.0002: : USB HID v0.00 Gamepad [shield] on
Tested on:
commit: 818bebeb drm/xe: Don't hand out the flat CCS storage a..
git tree: git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
console output: https://syzkaller.appspot.com/x/log.txt?x=166f5625580000
kernel config: https://syzkaller.appspot.com/x/.config?x=ccca94d2c01b9e78
dashboard link: https://syzkaller.appspot.com/bug?extid=dd764a450d93885d847f
compiler: gcc (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44
patch: https://syzkaller.appspot.com/x/patch.diff?x=128f6579580000
^ permalink raw reply [flat|nested] 28+ messages in thread
* [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
@ 2026-08-24 15:44 syzbot
0 siblings, 0 replies; 28+ messages in thread
From: syzbot @ 2026-08-24 15:44 UTC (permalink / raw)
To: davem, edumazet, horms, kuba, kuniyu, linux-kernel, ncardwell,
netdev, pabeni, syzkaller-bugs
Hello,
syzbot found the following issue on:
HEAD commit: 388b607d107c Merge tag 'efi-next-for-v7.3' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10f98979580000
kernel config: https://syzkaller.appspot.com/x/.config?x=335632b21d0ce540
dashboard link: https://syzkaller.appspot.com/bug?extid=2d770620059281e225a4
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=133c3549580000
Downloadable assets:
disk image: https://storage.googleapis.com/syzbot-assets/20c420e92df0/disk-388b607d.raw.xz
vmlinux: https://storage.googleapis.com/syzbot-assets/82f836a86dcc/vmlinux-388b607d.xz
kernel image: https://storage.googleapis.com/syzbot-assets/c3b00ac47be8/bzImage-388b607d.xz
IMPORTANT: if you fix the issue, please add the following tag to the commit:
Reported-by: syzbot+2d770620059281e225a4@syzkaller.appspotmail.com
------------[ cut here ]------------
DEBUG_LOCKS_WARN_ON(1)
WARNING: kernel/locking/lockdep.c:238 at hlock_class kernel/locking/lockdep.c:238 [inline], CPU#1: kworker/1:0/24
WARNING: kernel/locking/lockdep.c:238 at check_wait_context kernel/locking/lockdep.c:4870 [inline], CPU#1: kworker/1:0/24
WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203, CPU#1: kworker/1:0/24
Modules linked in:
CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]
RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline]
RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203
Code: 83 3d fa 48 f9 18 00 75 27 90 e8 b2 88 35 03 85 c0 74 1c 83 3d eb 3f d7 0e 00 75 13 48 8d 3d 1e 43 da 0e 48 c7 c6 8f 4c 59 8e <67> 48 0f b9 3a 90 31 c0 0f b6 98 c4 00 00 00 41 8b 45 20 25 ff 1f
RSP: 0018:ffffc90000a089b8 EFLAGS: 00010046
RAX: 0000000000000001 RBX: 0000000000042000 RCX: ffff88801eaaddc0
RDX: 8000000000000100 RSI: ffffffff8e594c8f RDI: ffffffff907cef80
RBP: 0000000000000001 R08: 0000000000000100 R09: 1ffffffff20f3d88
R10: dffffc0000000000 R11: fffffbfff20f3d89 R12: 0000000000000949
R13: ffff88801eaaea08 R14: ffff88801eaaddc0 R15: ffff88801eaae968
FS: 0000000000000000(0000) GS:ffff888124df4000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f390df782c0 CR3: 000000007747a000 CR4: 00000000003526f0
Call Trace:
<IRQ>
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886
__raw_spin_lock include/linux/spinlock_api_smp.h:190 [inline]
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173
spin_lock include/linux/spinlock.h:347 [inline]
tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291
tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325
process_one_work kernel/workqueue.c:3387 [inline]
process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
bh_worker+0x451/0x870 kernel/workqueue.c:3773
tasklet_action+0xc/0x70 kernel/softirq.c:997
handle_softirqs+0x226/0x860 kernel/softirq.c:645
do_softirq+0x77/0xd0 kernel/softirq.c:546
</IRQ>
<TASK>
__local_bh_enable_ip+0x100/0x140 kernel/softirq.c:473
wg_socket_send_skb_to_peer+0x16b/0x1d0 drivers/net/wireguard/socket.c:183
wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline]
wg_packet_tx_worker+0x1c8/0x7e0 drivers/net/wireguard/send.c:276
process_one_work kernel/workqueue.c:3387 [inline]
process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551
kthread+0x38b/0x480 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
----------------
Code disassembly (best guess):
0: 83 3d fa 48 f9 18 00 cmpl $0x0,0x18f948fa(%rip) # 0x18f94901
7: 75 27 jne 0x30
9: 90 nop
a: e8 b2 88 35 03 call 0x33588c1
f: 85 c0 test %eax,%eax
11: 74 1c je 0x2f
13: 83 3d eb 3f d7 0e 00 cmpl $0x0,0xed73feb(%rip) # 0xed74005
1a: 75 13 jne 0x2f
1c: 48 8d 3d 1e 43 da 0e lea 0xeda431e(%rip),%rdi # 0xeda4341
23: 48 c7 c6 8f 4c 59 8e mov $0xffffffff8e594c8f,%rsi
* 2a: 67 48 0f b9 3a ud1 (%edx),%rdi <-- trapping instruction
2f: 90 nop
30: 31 c0 xor %eax,%eax
32: 0f b6 98 c4 00 00 00 movzbl 0xc4(%rax),%ebx
39: 41 8b 45 20 mov 0x20(%r13),%eax
3d: 25 .byte 0x25
3e: ff 1f lcall *(%rdi)
---
This report is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkaller@googlegroups.com.
syzbot will keep track of this issue. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
If the report is already addressed, let syzbot know by replying with:
#syz fix: exact-commit-title
If you want syzbot to run the reproducer, reply with:
#syz test: git://repo/address.git branch-or-commit-hash
If you attach or paste a git patch, syzbot will apply it before testing.
If you want to overwrite report's subsystems, reply with:
#syz set subsystems: new-subsystem
(See the list of subsystem names on the web dashboard)
If the report is a duplicate of another one, reply with:
#syz dup: exact-subject-of-another-report
If you want to undo deduplication, reply with:
#syz undup
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [PATCH] locking/lockdep: Invalidate stale class_cache entries for zapped classes
@ 2026-08-25 0:29 Hillf Danton
2026-08-25 0:59 ` [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler syzbot
0 siblings, 1 reply; 28+ messages in thread
From: Hillf Danton @ 2026-08-25 0:29 UTC (permalink / raw)
To: syzbot+2d770620059281e225a4
Cc: Peter Zijlstra, Boqun Feng, linux-kernel, netdev, Eric Dumazet
#syz test
syzbot reported a lockdep splat hitting DEBUG_LOCKS_WARN_ON(1) in
hlock_class() due to an invalid class_idx:
WARNING: kernel/locking/lockdep.c:238 at __lock_acquire+0x382/0x2cf0 kernel/locking/lockdep.c:5203
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
RIP: 0010:hlock_class kernel/locking/lockdep.c:238 [inline]
RIP: 0010:check_wait_context kernel/locking/lockdep.c:4870 [inline]
RIP: 0010:__lock_acquire+0x389/0x2cf0 kernel/locking/lockdep.c:5203
Call Trace:
<IRQ>
lock_acquire+0x106/0x350 kernel/locking/lockdep.c:5886
_raw_spin_lock+0x2e/0x40 kernel/locking/spinlock.c:173
tcp_tsq_handler+0x29/0x200 net/ipv4/tcp_output.c:1291
tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325
...
When a lock class is zapped (e.g. during module unload or key
unregistration), zap_class() clears the class's bit in
lock_classes_in_use and removes it from the class hash table.
However, existing lockdep_map instances embedded in data structures
may still retain a pointer to the zapped class in their class_cache[]
array.
When __lock_acquire() subsequently runs on such a lock, it finds
lock->class_cache[subclass] != NULL, skipping register_lock_class() and
assigning hlock->class_idx to the index of the zapped class. When
check_wait_context() or hlock_class() inspects the held_lock, it finds
!test_bit(class_idx, lock_classes_in_use) and warns. Furthermore, if
the zapped slot is subsequently re-allocated to an unrelated lock key,
the stale class_cache entry would erroneously match the unrelated class
(ABA issue).
Add lock_class_cache_is_valid() to validate that the cached class is
within lock_classes bounds, still allocated in lock_classes_in_use
(using uninstrumented arch_test_bit() in __always_inline context so it
is safe in noinstr contexts like match_held_lock()), and that class->key
matches the expected subkey (taking lockdep_set_subclass() overrides into
account). Also use READ_ONCE()/WRITE_ONCE() when accessing class_cache[].
If the entry is invalid or stale, fall back to register_lock_class() /
look_up_lock_class().
Fixes: a0b0fd53e1e6 ("locking/lockdep: Free lock classes that are no longer in use")
Reported-by: syzbot+2d770620059281e225a4@syzkaller.appspotmail.com
Closes: https://lore.kernel.org/netdev/6a8c66dc.4d75e56a.c9a88.0050.GAE@google.com/T/#u
Assisted-by: Gemini:gemini-3.1-pro
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
kernel/locking/lockdep.c | 50 +++++++++++++++++++++++++++++++++-------
1 file changed, 42 insertions(+), 8 deletions(-)
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index 25d77d4a1061..763f79806bd8 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -963,6 +963,34 @@ look_up_lock_class(const struct lockdep_map *lock, unsigned int subclass)
return NULL;
}
+static __always_inline bool lock_class_cache_is_valid(const struct lockdep_map *lock,
+ const struct lock_class *class,
+ unsigned int subclass)
+{
+ unsigned int class_subclass;
+
+ if (!class)
+ return false;
+
+ if (unlikely(class < lock_classes || class >= lock_classes + MAX_LOCKDEP_KEYS))
+ return false;
+
+ if (unlikely(!arch_test_bit(class - lock_classes, lock_classes_in_use)))
+ return false;
+
+ if (unlikely(!lock->key))
+ return false;
+
+ class_subclass = subclass ? subclass : class->subclass;
+ if (unlikely(class_subclass >= MAX_LOCKDEP_SUBCLASSES))
+ return false;
+
+ if (unlikely(READ_ONCE(class->key) != lock->key->subkeys + class_subclass))
+ return false;
+
+ return true;
+}
+
/*
* Static locks do not have their class-keys yet - for them the key is
* the lock object itself. If the lock is in the per cpu area, the
@@ -1395,9 +1423,9 @@ register_lock_class(struct lockdep_map *lock, unsigned int subclass, int force)
out_set_class_cache:
if (!subclass || force)
- lock->class_cache[0] = class;
+ WRITE_ONCE(lock->class_cache[0], class);
else if (subclass < NR_LOCKDEP_CACHING_CLASSES)
- lock->class_cache[subclass] = class;
+ WRITE_ONCE(lock->class_cache[subclass], class);
/*
* Hash collision, did we smoke some? We found a class with a matching
@@ -4957,7 +4985,7 @@ void lockdep_init_map_type(struct lockdep_map *lock, const char *name,
int i;
for (i = 0; i < NR_LOCKDEP_CACHING_CLASSES; i++)
- lock->class_cache[i] = NULL;
+ WRITE_ONCE(lock->class_cache[i], NULL);
#ifdef CONFIG_LOCK_STAT
lock->cpu = raw_smp_processor_id();
@@ -5022,12 +5050,15 @@ EXPORT_SYMBOL_GPL(__lockdep_no_track__);
void lockdep_set_lock_cmp_fn(struct lockdep_map *lock, lock_cmp_fn cmp_fn,
lock_print_fn print_fn)
{
- struct lock_class *class = lock->class_cache[0];
+ struct lock_class *class = READ_ONCE(lock->class_cache[0]);
unsigned long flags;
raw_local_irq_save(flags);
lockdep_recursion_inc();
+ if (!lock_class_cache_is_valid(lock, class, 0))
+ class = NULL;
+
if (!class)
class = register_lock_class(lock, 0, 0);
@@ -5119,8 +5150,11 @@ static int __lock_acquire(struct lockdep_map *lock, unsigned int subclass,
if (DEBUG_LOCKS_WARN_ON(subclass >= MAX_LOCKDEP_SUBCLASSES))
return 0;
- if (subclass < NR_LOCKDEP_CACHING_CLASSES)
- class = lock->class_cache[subclass];
+ if (subclass < NR_LOCKDEP_CACHING_CLASSES) {
+ class = READ_ONCE(lock->class_cache[subclass]);
+ if (!lock_class_cache_is_valid(lock, class, subclass))
+ class = NULL;
+ }
/*
* Not cached?
*/
@@ -5323,9 +5357,9 @@ static noinstr int match_held_lock(const struct held_lock *hlock,
return 1;
if (hlock->references) {
- const struct lock_class *class = lock->class_cache[0];
+ const struct lock_class *class = READ_ONCE(lock->class_cache[0]);
- if (!class)
+ if (!lock_class_cache_is_valid(lock, class, 0))
class = look_up_lock_class(lock, 0);
/*
base-commit: 0a0d1d55dad570724bf8c7ea83409639cfb4be9b
--
2.55.0.766.g2966f0265a-goog
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 0:29 [PATCH] locking/lockdep: Invalidate stale class_cache entries for zapped classes Hillf Danton
@ 2026-08-25 0:59 ` syzbot
2026-08-25 1:25 ` Hillf Danton
2026-08-25 1:27 ` Eric Dumazet
0 siblings, 2 replies; 28+ messages in thread
From: syzbot @ 2026-08-25 0:59 UTC (permalink / raw)
To: boqun, edumazet, hdanton, linux-kernel, netdev, peterz, syzkaller-bugs
Hello,
syzbot has tested the proposed patch but the reproducer is still triggering an issue:
WARNING in tcp_tsq_handler
------------[ cut here ]------------
!lockdep_sock_is_held(sk) && debug_locks
WARNING: ./include/net/sock.h:1799 at sock_owned_by_me include/net/sock.h:1799 [inline], CPU#1: kworker/1:0/24
WARNING: ./include/net/sock.h:1799 at sock_owned_by_user include/net/sock.h:1812 [inline], CPU#1: kworker/1:0/24
WARNING: ./include/net/sock.h:1799 at tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292, CPU#1: kworker/1:0/24
Modules linked in:
CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0 Not tainted syzkaller #0 PREEMPT(full)
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
Workqueue: wg-crypt-wg0 wg_packet_tx_worker
RIP: 0010:sock_owned_by_me include/net/sock.h:1799 [inline]
RIP: 0010:sock_owned_by_user include/net/sock.h:1812 [inline]
RIP: 0010:tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292
Code: 30 96 96 01 e8 7b b3 7a f7 be 02 00 00 00 eb 0a e8 6f b3 7a f7 be 01 00 00 00 4c 89 ff e8 82 3e 8f fa eb d0 e8 5b b3 7a f7 90 <0f> 0b 90 e9 fd fe ff ff 44 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 07
RSP: 0018:ffffc90000a08bb0 EFLAGS: 00010246
RAX: ffffffff8a4c8ba5 RBX: ffff88802db742d0 RCX: ffff88801e6e5dc0
RDX: 8000000000000100 RSI: 0000000000000100 RDI: 0000000000000000
RBP: 0000000000000001 R08: 0000000000000100 R09: 0000000000000004
R10: dffffc0000000000 R11: fffff52000141164 R12: dffffc0000000000
R13: ffffc90000a08c20 R14: ffff88802db74100 R15: ffff88802db74100
FS: 0000000000000000(0000) GS:ffff888124df1000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00005635f5ecdbd8 CR3: 0000000072ba6000 CR4: 00000000003526f0
Call Trace:
<IRQ>
tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325
process_one_work kernel/workqueue.c:3387 [inline]
process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
bh_worker+0x451/0x870 kernel/workqueue.c:3773
tasklet_action+0xc/0x70 kernel/softirq.c:997
handle_softirqs+0x226/0x860 kernel/softirq.c:645
do_softirq+0x77/0xd0 kernel/softirq.c:546
</IRQ>
<TASK>
__local_bh_enable_ip+0x100/0x140 kernel/softirq.c:473
wg_socket_send_skb_to_peer+0x16b/0x1d0 drivers/net/wireguard/socket.c:183
wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline]
wg_packet_tx_worker+0x1c8/0x7e0 drivers/net/wireguard/send.c:276
process_one_work kernel/workqueue.c:3387 [inline]
process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551
kthread+0x38b/0x480 kernel/kthread.c:436
ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
</TASK>
Tested on:
commit: 66498c75 Merge tag 'dmaengine-7.3-rc1' of git://git.ke..
git tree: upstream
console output: https://syzkaller.appspot.com/x/log.txt?x=10adc979580000
kernel config: https://syzkaller.appspot.com/x/.config?x=e9ce1d694820ba2b
dashboard link: https://syzkaller.appspot.com/bug?extid=2d770620059281e225a4
compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
patch: https://syzkaller.appspot.com/x/patch.diff?x=1497b549580000
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 0:59 ` [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler syzbot
@ 2026-08-25 1:25 ` Hillf Danton
2026-08-25 1:27 ` Eric Dumazet
1 sibling, 0 replies; 28+ messages in thread
From: Hillf Danton @ 2026-08-25 1:25 UTC (permalink / raw)
To: syzbot; +Cc: boqun, edumazet, linux-kernel, netdev, peterz, syzkaller-bugs
> Date: Mon, 24 Aug 2026 17:59:01 -0700 [thread overview]
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> WARNING in tcp_tsq_handler
>
Fine, another case of HBC, half baked croissant, thanks to syzbot.
> ------------[ cut here ]------------
> !lockdep_sock_is_held(sk) && debug_locks
> WARNING: ./include/net/sock.h:1799 at sock_owned_by_me include/net/sock.h:1799 [inline], CPU#1: kworker/1:0/24
> WARNING: ./include/net/sock.h:1799 at sock_owned_by_user include/net/sock.h:1812 [inline], CPU#1: kworker/1:0/24
> WARNING: ./include/net/sock.h:1799 at tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292, CPU#1: kworker/1:0/24
> Modules linked in:
> CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
> Workqueue: wg-crypt-wg0 wg_packet_tx_worker
> RIP: 0010:sock_owned_by_me include/net/sock.h:1799 [inline]
> RIP: 0010:sock_owned_by_user include/net/sock.h:1812 [inline]
> RIP: 0010:tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292
> Code: 30 96 96 01 e8 7b b3 7a f7 be 02 00 00 00 eb 0a e8 6f b3 7a f7 be 01 00 00 00 4c 89 ff e8 82 3e 8f fa eb d0 e8 5b b3 7a f7 90 <0f> 0b 90 e9 fd fe ff ff 44 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 07
> RSP: 0018:ffffc90000a08bb0 EFLAGS: 00010246
> RAX: ffffffff8a4c8ba5 RBX: ffff88802db742d0 RCX: ffff88801e6e5dc0
> RDX: 8000000000000100 RSI: 0000000000000100 RDI: 0000000000000000
> RBP: 0000000000000001 R08: 0000000000000100 R09: 0000000000000004
> R10: dffffc0000000000 R11: fffff52000141164 R12: dffffc0000000000
> R13: ffffc90000a08c20 R14: ffff88802db74100 R15: ffff88802db74100
> FS: 0000000000000000(0000) GS:ffff888124df1000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005635f5ecdbd8 CR3: 0000000072ba6000 CR4: 00000000003526f0
> Call Trace:
> <IRQ>
> tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325
> process_one_work kernel/workqueue.c:3387 [inline]
> process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
> bh_worker+0x451/0x870 kernel/workqueue.c:3773
> tasklet_action+0xc/0x70 kernel/softirq.c:997
> handle_softirqs+0x226/0x860 kernel/softirq.c:645
> do_softirq+0x77/0xd0 kernel/softirq.c:546
> </IRQ>
> <TASK>
> __local_bh_enable_ip+0x100/0x140 kernel/softirq.c:473
> wg_socket_send_skb_to_peer+0x16b/0x1d0 drivers/net/wireguard/socket.c:183
> wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline]
> wg_packet_tx_worker+0x1c8/0x7e0 drivers/net/wireguard/send.c:276
> process_one_work kernel/workqueue.c:3387 [inline]
> process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
> worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551
> kthread+0x38b/0x480 kernel/kthread.c:436
> ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> </TASK>
>
>
> Tested on:
>
> commit: 66498c75 Merge tag 'dmaengine-7.3-rc1' of git://git.ke..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10adc979580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e9ce1d694820ba2b
> dashboard link: https://syzkaller.appspot.com/bug?extid=2d770620059281e225a4
> compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> patch: https://syzkaller.appspot.com/x/patch.diff?x=1497b549580000
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 0:59 ` [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler syzbot
2026-08-25 1:25 ` Hillf Danton
@ 2026-08-25 1:27 ` Eric Dumazet
2026-08-25 1:50 ` Eric Dumazet
1 sibling, 1 reply; 28+ messages in thread
From: Eric Dumazet @ 2026-08-25 1:27 UTC (permalink / raw)
To: syzbot, Shin'ichiro Kawasaki, Nilay Shroff, Keith Busch
Cc: boqun, hdanton, linux-kernel, netdev, peterz, syzkaller-bugs
On Tue, Aug 25, 2026 at 2:59 AM syzbot
<syzbot+2d770620059281e225a4@syzkaller.appspotmail.com> wrote:
>
> Hello,
>
> syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> WARNING in tcp_tsq_handler
>
> ------------[ cut here ]------------
> !lockdep_sock_is_held(sk) && debug_locks
> WARNING: ./include/net/sock.h:1799 at sock_owned_by_me include/net/sock.h:1799 [inline], CPU#1: kworker/1:0/24
> WARNING: ./include/net/sock.h:1799 at sock_owned_by_user include/net/sock.h:1812 [inline], CPU#1: kworker/1:0/24
> WARNING: ./include/net/sock.h:1799 at tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292, CPU#1: kworker/1:0/24
Note this is a different warning.
This one might have been added in nvme-tcp in commit
commit 19bdb70c77d3b24239a453291299b64040bdba86
Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Date: Thu Jun 4 11:32:08 2026 +0900
nvme-tcp: lockdep: use dynamic lockdep keys per socket instance
The authors assumed that __fput_sync(queue->sock->file) in
nvme_tcp_free_queue() synchronously destroys the socket, so they
unregistered the keys immediately:
__fput_sync(queue->sock->file);
queue->sock = NULL;
...
#ifdef CONFIG_DEBUG_LOCK_ALLOC
lockdep_unregister_key(&queue->nvme_tcp_sk_key);
lockdep_unregister_key(&queue->nvme_tcp_slock_key);
#endif
However, a TCP socket's lifetime is asynchronous:
in-flight skbs (e.g. buffered in a qdisc or device ring) hold
references on sk->sk_wmem_alloc.
When those packets are freed later, tcp_wfree() puts sk on TSQ and
tcp_tsq_handler(sk)
acquires bh_lock_sock(sk) on a socket whose lockdep key has already
been unregistered and zapped.
All other kernel storage/networking clients (sunrpc, nbd, cifs,
iscsi_tcp, rxe, siw) use static lockdep keys without issue.
> Modules linked in:
> CPU: 1 UID: 0 PID: 24 Comm: kworker/1:0 Not tainted syzkaller #0 PREEMPT(full)
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 07/24/2026
> Workqueue: wg-crypt-wg0 wg_packet_tx_worker
> RIP: 0010:sock_owned_by_me include/net/sock.h:1799 [inline]
> RIP: 0010:sock_owned_by_user include/net/sock.h:1812 [inline]
> RIP: 0010:tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292
> Code: 30 96 96 01 e8 7b b3 7a f7 be 02 00 00 00 eb 0a e8 6f b3 7a f7 be 01 00 00 00 4c 89 ff e8 82 3e 8f fa eb d0 e8 5b b3 7a f7 90 <0f> 0b 90 e9 fd fe ff ff 44 89 f9 80 e1 07 80 c1 03 38 c1 0f 8c 07
> RSP: 0018:ffffc90000a08bb0 EFLAGS: 00010246
> RAX: ffffffff8a4c8ba5 RBX: ffff88802db742d0 RCX: ffff88801e6e5dc0
> RDX: 8000000000000100 RSI: 0000000000000100 RDI: 0000000000000000
> RBP: 0000000000000001 R08: 0000000000000100 R09: 0000000000000004
> R10: dffffc0000000000 R11: fffff52000141164 R12: dffffc0000000000
> R13: ffffc90000a08c20 R14: ffff88802db74100 R15: ffff88802db74100
> FS: 0000000000000000(0000) GS:ffff888124df1000(0000) knlGS:0000000000000000
> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> CR2: 00005635f5ecdbd8 CR3: 0000000072ba6000 CR4: 00000000003526f0
> Call Trace:
> <IRQ>
> tcp_tsq_workfn+0x384/0x410 net/ipv4/tcp_output.c:1325
> process_one_work kernel/workqueue.c:3387 [inline]
> process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
> bh_worker+0x451/0x870 kernel/workqueue.c:3773
> tasklet_action+0xc/0x70 kernel/softirq.c:997
> handle_softirqs+0x226/0x860 kernel/softirq.c:645
> do_softirq+0x77/0xd0 kernel/softirq.c:546
> </IRQ>
> <TASK>
> __local_bh_enable_ip+0x100/0x140 kernel/softirq.c:473
> wg_socket_send_skb_to_peer+0x16b/0x1d0 drivers/net/wireguard/socket.c:183
> wg_packet_create_data_done drivers/net/wireguard/send.c:251 [inline]
> wg_packet_tx_worker+0x1c8/0x7e0 drivers/net/wireguard/send.c:276
> process_one_work kernel/workqueue.c:3387 [inline]
> process_scheduled_works+0xc3d/0x1630 kernel/workqueue.c:3470
> worker_thread+0xa47/0xfb0 kernel/workqueue.c:3551
> kthread+0x38b/0x480 kernel/kthread.c:436
> ret_from_fork+0x514/0xb70 arch/x86/kernel/process.c:158
> ret_from_fork_asm+0x1a/0x30 arch/x86/entry/entry_64.S:245
> </TASK>
>
>
> Tested on:
>
> commit: 66498c75 Merge tag 'dmaengine-7.3-rc1' of git://git.ke..
> git tree: upstream
> console output: https://syzkaller.appspot.com/x/log.txt?x=10adc979580000
> kernel config: https://syzkaller.appspot.com/x/.config?x=e9ce1d694820ba2b
> dashboard link: https://syzkaller.appspot.com/bug?extid=2d770620059281e225a4
> compiler: Debian clang version 22.1.8 (++20260613092233+e80beda6e255-1~exp1~20260613092250.77), Debian LLD 22.1.8
> patch: https://syzkaller.appspot.com/x/patch.diff?x=1497b549580000
>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 1:27 ` Eric Dumazet
@ 2026-08-25 1:50 ` Eric Dumazet
2026-08-25 5:44 ` Shin'ichiro Kawasaki
0 siblings, 1 reply; 28+ messages in thread
From: Eric Dumazet @ 2026-08-25 1:50 UTC (permalink / raw)
To: syzbot, Shin'ichiro Kawasaki, Nilay Shroff, Keith Busch
Cc: boqun, hdanton, linux-kernel, netdev, peterz, syzkaller-bugs
On Tue, Aug 25, 2026 at 3:27 AM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Aug 25, 2026 at 2:59 AM syzbot
> <syzbot+2d770620059281e225a4@syzkaller.appspotmail.com> wrote:
> >
> > Hello,
> >
> > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > WARNING in tcp_tsq_handler
> >
> > ------------[ cut here ]------------
> > !lockdep_sock_is_held(sk) && debug_locks
> > WARNING: ./include/net/sock.h:1799 at sock_owned_by_me include/net/sock.h:1799 [inline], CPU#1: kworker/1:0/24
> > WARNING: ./include/net/sock.h:1799 at sock_owned_by_user include/net/sock.h:1812 [inline], CPU#1: kworker/1:0/24
> > WARNING: ./include/net/sock.h:1799 at tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292, CPU#1: kworker/1:0/24
>
> Note this is a different warning.
>
> This one might have been added in nvme-tcp in commit
>
> commit 19bdb70c77d3b24239a453291299b64040bdba86
> Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> Date: Thu Jun 4 11:32:08 2026 +0900
>
> nvme-tcp: lockdep: use dynamic lockdep keys per socket instance
>
> The authors assumed that __fput_sync(queue->sock->file) in
> nvme_tcp_free_queue() synchronously destroys the socket, so they
> unregistered the keys immediately:
>
> __fput_sync(queue->sock->file);
> queue->sock = NULL;
> ...
> #ifdef CONFIG_DEBUG_LOCK_ALLOC
> lockdep_unregister_key(&queue->nvme_tcp_sk_key);
> lockdep_unregister_key(&queue->nvme_tcp_slock_key);
> #endif
>
> However, a TCP socket's lifetime is asynchronous:
> in-flight skbs (e.g. buffered in a qdisc or device ring) hold
> references on sk->sk_wmem_alloc.
>
> When those packets are freed later, tcp_wfree() puts sk on TSQ and
> tcp_tsq_handler(sk)
> acquires bh_lock_sock(sk) on a socket whose lockdep key has already
> been unregistered and zapped.
>
> All other kernel storage/networking clients (sunrpc, nbd, cifs,
> iscsi_tcp, rxe, siw) use static lockdep keys without issue.
>
I think 19bdb70c77d3 should be reverted.
We can change TCP to use sk_gfp_mask(sk, GFP_ATOMIC) instead of
gfp_any() in tcp_disconnect()
This ensures tcp_disconnect() respects sk->sk_allocation = GFP_ATOMIC
and never acquires fs_reclaim under sk_lock.
WDYT?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 1:50 ` Eric Dumazet
@ 2026-08-25 5:44 ` Shin'ichiro Kawasaki
2026-08-25 6:25 ` Hillf Danton
` (2 more replies)
0 siblings, 3 replies; 28+ messages in thread
From: Shin'ichiro Kawasaki @ 2026-08-25 5:44 UTC (permalink / raw)
To: Eric Dumazet
Cc: syzbot, Nilay Shroff, Keith Busch, boqun, hdanton, linux-kernel,
netdev, peterz, syzkaller-bugs
On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> On Tue, Aug 25, 2026 at 3:27 AM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Tue, Aug 25, 2026 at 2:59 AM syzbot
> > <syzbot+2d770620059281e225a4@syzkaller.appspotmail.com> wrote:
> > >
> > > Hello,
> > >
> > > syzbot has tested the proposed patch but the reproducer is still triggering an issue:
> > > WARNING in tcp_tsq_handler
> > >
> > > ------------[ cut here ]------------
> > > !lockdep_sock_is_held(sk) && debug_locks
> > > WARNING: ./include/net/sock.h:1799 at sock_owned_by_me include/net/sock.h:1799 [inline], CPU#1: kworker/1:0/24
> > > WARNING: ./include/net/sock.h:1799 at sock_owned_by_user include/net/sock.h:1812 [inline], CPU#1: kworker/1:0/24
> > > WARNING: ./include/net/sock.h:1799 at tcp_tsq_handler+0x1a6/0x200 net/ipv4/tcp_output.c:1292, CPU#1: kworker/1:0/24
> >
> > Note this is a different warning.
> >
> > This one might have been added in nvme-tcp in commit
> >
> > commit 19bdb70c77d3b24239a453291299b64040bdba86
> > Author: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
> > Date: Thu Jun 4 11:32:08 2026 +0900
> >
> > nvme-tcp: lockdep: use dynamic lockdep keys per socket instance
> >
> > The authors assumed that __fput_sync(queue->sock->file) in
> > nvme_tcp_free_queue() synchronously destroys the socket, so they
> > unregistered the keys immediately:
> >
> > __fput_sync(queue->sock->file);
> > queue->sock = NULL;
> > ...
> > #ifdef CONFIG_DEBUG_LOCK_ALLOC
> > lockdep_unregister_key(&queue->nvme_tcp_sk_key);
> > lockdep_unregister_key(&queue->nvme_tcp_slock_key);
> > #endif
> >
> > However, a TCP socket's lifetime is asynchronous:
> > in-flight skbs (e.g. buffered in a qdisc or device ring) hold
> > references on sk->sk_wmem_alloc.
> >
> > When those packets are freed later, tcp_wfree() puts sk on TSQ and
> > tcp_tsq_handler(sk)
> > acquires bh_lock_sock(sk) on a socket whose lockdep key has already
> > been unregistered and zapped.
> >
> > All other kernel storage/networking clients (sunrpc, nbd, cifs,
> > iscsi_tcp, rxe, siw) use static lockdep keys without issue.
> >
>
> I think 19bdb70c77d3 should be reverted.
Just reverting the commit will reintroduce the other lockdep WARN that the
commit addressed. I hope to have another fix to avoid the WARN.
>
> We can change TCP to use sk_gfp_mask(sk, GFP_ATOMIC) instead of
> gfp_any() in tcp_disconnect()
>
> This ensures tcp_disconnect() respects sk->sk_allocation = GFP_ATOMIC
> and never acquires fs_reclaim under sk_lock.
>
> WDYT?
Thanks for the idea. I did a quick trial with the idea.
Step 1:
I reverted the commit 19bdb70c77d3 from v7.2 kernel, and confirmed that
the blktests test case nvme/005 for tcp transport recreates the lockdep
WARN that includes fs_reclaim in its lock chain.
Step 2:
I created a patch to replace gfp_any() in tcp_disconnect() with GFP_ATOMIC
[1]. I applied this patch to the v7.2 based kernel that I used in the step 1.
I ran the test case nvme/005 on this kernel, and observed it still fails
with the lockdep WARN: fs_reclaim was still included in the lock chain.
I think this is expected, since fs_reclaim dependency comes from CPU hotplug
bring-up context.
Based on this observation, I'm afraid that using GFP_ATOMIC in tcp_disconnect()
won't work, unfortunately.
Another approach I can think of is to use sk->sk_destruct hook to unregister
keys, so that the unregistraion happens after the all in-flight skbs complete.
I will try this approach.
[1] fix trial patch
diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 455441f1b694..861ce399eee3 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -3376,14 +3376,14 @@ int tcp_disconnect(struct sock *sk, int flags)
} else if (unlikely(tp->repair)) {
WRITE_ONCE(sk->sk_err, ECONNABORTED);
} else if (tcp_need_reset(old_state)) {
- tcp_send_active_reset(sk, gfp_any(), SK_RST_REASON_TCP_STATE);
+ tcp_send_active_reset(sk, GFP_ATOMIC, SK_RST_REASON_TCP_STATE);
WRITE_ONCE(sk->sk_err, ECONNRESET);
} else if (tp->snd_nxt != tp->write_seq &&
(1 << old_state) & (TCPF_CLOSING | TCPF_LAST_ACK)) {
/* The last check adjusts for discrepancy of Linux wrt. RFC
* states
*/
- tcp_send_active_reset(sk, gfp_any(),
+ tcp_send_active_reset(sk, GFP_ATOMIC,
SK_RST_REASON_TCP_DISCONNECT_WITH_DATA);
WRITE_ONCE(sk->sk_err, ECONNRESET);
} else if (old_state == TCP_SYN_SENT)
[2] Lockdep WARN observed at the step 2
[ 86.005477] [ T995] run blktests nvme/005 at 2026-08-25 13:52:07
[ 86.164051] [ T1069] loop0: detected capacity change from 0 to 2097152
[ 86.204542] [ T1073] nvmet: adding nsid 1 to subsystem blktests-subsystem-1
[ 86.274053] [ T1079] nvmet_tcp: enabling port 0 (127.0.0.1:4420)
[ 86.483498] [ T104] nvmet: Created nvm controller 1 for subsystem blktests-subsystem-1 for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
[ 86.493643] [ T1089] nvme nvme5: creating 4 I/O queues.
[ 86.503743] [ T1089] nvme nvme5: mapped 4/0/0 default/read/poll queues.
[ 86.510474] [ T1089] nvme nvme5: new ctrl: NQN "blktests-subsystem-1", addr 127.0.0.1:4420, hostnqn: nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349
[ 87.138148] [ T103] nvmet: Created nvm controller 2 for subsystem blktests-subsystem-1 for NQN nqn.2014-08.org.nvmexpress:uuid:0f01fb42-9f7f-4856-b0b3-51e60b8de349.
[ 87.145904] [ T83] nvme nvme5: creating 4 I/O queues.
[ 87.167642] [ T83] nvme nvme5: mapped 4/0/0 default/read/poll queues.
[ 87.274245] [ T1137] nvme nvme5: Removing ctrl: NQN "blktests-subsystem-1"
[ 87.291121] [ T1137] ======================================================
[ 87.292008] [ T1137] WARNING: possible circular locking dependency detected
[ 87.292880] [ T1137] 7.2.0+ #669 Not tainted
[ 87.293454] [ T1137] ------------------------------------------------------
[ 87.294356] [ T1137] nvme/1137 is trying to acquire lock:
[ 87.295070] [ T1137] ffff88812e989518 (set->srcu){.+.+}-{0:0}, at: __synchronize_srcu+0xc1/0x2f0
[ 87.296192] [ T1137]
but task is already holding lock:
[ 87.297124] [ T1137] ffff88813bebaac8 (&q->elevator_lock){+.+.}-{4:4}, at: elevator_change+0x197/0x500
[ 87.298299] [ T1137]
which lock already depends on the new lock.
[ 87.299570] [ T1137]
the existing dependency chain (in reverse order) is:
[ 87.300685] [ T1137]
-> #5 (&q->elevator_lock){+.+.}-{4:4}:
[ 87.301657] [ T1137] __mutex_lock+0x1ae/0x2500
[ 87.302338] [ T1137] elevator_change+0x197/0x500
[ 87.303047] [ T1137] elv_iosched_store+0x38f/0x430
[ 87.303719] [ T1137] queue_attr_store+0x25f/0x3e0
[ 87.304377] [ T1137] kernfs_fop_write_iter+0x3d6/0x5e0
[ 87.305121] [ T1137] vfs_write+0x4b3/0xf40
[ 87.305747] [ T1137] ksys_write+0x112/0x250
[ 87.306821] [ T1137] do_syscall_64+0xdf/0x790
[ 87.307851] [ T1137] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.309110] [ T1137]
-> #4 (&q->q_usage_counter(io)){++++}-{0:0}:
[ 87.310932] [ T1137] blk_alloc_queue+0x605/0x7a0
[ 87.312034] [ T1137] blk_mq_alloc_queue+0x168/0x270
[ 87.313138] [ T1137] scsi_alloc_sdev+0x8df/0xd10
[ 87.314229] [ T1137] scsi_probe_and_add_lun+0x5bd/0xbf0
[ 87.315381] [ T1137] __scsi_add_device+0x233/0x280
[ 87.316480] [ T1137] ata_scsi_scan_host+0x137/0x3a0
[ 87.317560] [ T1137] async_run_entry_fn+0x93/0x550
[ 87.318616] [ T1137] process_one_work+0x8b2/0x15e0
[ 87.319657] [ T1137] worker_thread+0x5fd/0xfe0
[ 87.320653] [ T1137] kthread+0x367/0x460
[ 87.321592] [ T1137] ret_from_fork+0x655/0x9d0
[ 87.322577] [ T1137] ret_from_fork_asm+0x1a/0x30
[ 87.323571] [ T1137]
-> #3 (fs_reclaim){+.+.}-{0:0}:
[ 87.325134] [ T1137] fs_reclaim_acquire+0xd5/0x120
[ 87.326174] [ T1137] __kmalloc_cache_node_noprof+0x67/0x6f0
[ 87.327258] [ T1137] create_worker+0x117/0x790
[ 87.328234] [ T1137] workqueue_prepare_cpu+0x93/0xf0
[ 87.329219] [ T1137] cpuhp_invoke_callback+0x2c5/0x11f0
[ 87.330236] [ T1137] __cpuhp_invoke_callback_range+0xb6/0x1e0
[ 87.331303] [ T1137] _cpu_up+0x2eb/0x6d0
[ 87.332204] [ T1137] cpu_up+0x111/0x190
[ 87.333062] [ T1137] cpuhp_bringup_mask+0xd3/0x110
[ 87.334049] [ T1137] bringup_nonboot_cpus+0x139/0x170
[ 87.335075] [ T1137] smp_init+0x27/0xe0
[ 87.335914] [ T1137] kernel_init_freeable+0x442/0x710
[ 87.336905] [ T1137] kernel_init+0x18/0x150
[ 87.337769] [ T1137] ret_from_fork+0x655/0x9d0
[ 87.338655] [ T1137] ret_from_fork_asm+0x1a/0x30
[ 87.339554] [ T1137]
-> #2 (cpu_hotplug_lock){++++}-{0:0}:
[ 87.340978] [ T1137] cpus_read_lock+0x3c/0xe0
[ 87.341886] [ T1137] static_key_disable+0x12/0x30
[ 87.342790] [ T1137] __inet_hash_connect+0xf7f/0x1a60
[ 87.343727] [ T1137] tcp_v4_connect+0xcb7/0x1970
[ 87.344619] [ T1137] __inet_stream_connect+0x399/0xfb0
[ 87.345570] [ T1137] inet_stream_connect+0x55/0xb0
[ 87.346474] [ T1137] kernel_connect+0x103/0x170
[ 87.347385] [ T1137] nvme_tcp_alloc_queue+0xa48/0x1ba0 [nvme_tcp]
[ 87.348457] [ T1137] nvme_tcp_alloc_admin_queue+0xff/0x440 [nvme_tcp]
[ 87.349569] [ T1137] nvme_tcp_setup_ctrl+0xad/0x8a0 [nvme_tcp]
[ 87.350603] [ T1137] nvme_tcp_create_ctrl+0x874/0xc20 [nvme_tcp]
[ 87.351646] [ T1137] nvmf_dev_write+0x40b/0x830 [nvme_fabrics]
[ 87.352660] [ T1137] vfs_write+0x1cc/0xf40
[ 87.353468] [ T1137] ksys_write+0x112/0x250
[ 87.354310] [ T1137] do_syscall_64+0xdf/0x790
[ 87.355175] [ T1137] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.356196] [ T1137]
-> #1 (sk_lock-AF_INET-NVME){+.+.}-{0:0}:
[ 87.357635] [ T1137] lock_sock_nested+0x32/0xf0
[ 87.358491] [ T1137] tcp_sendmsg+0x1c/0x50
[ 87.359322] [ T1137] sock_sendmsg+0x31c/0x3f0
[ 87.360180] [ T1137] nvme_tcp_try_send_cmd_pdu+0x60e/0xcc0 [nvme_tcp]
[ 87.361282] [ T1137] nvme_tcp_try_send+0x1ef/0xa60 [nvme_tcp]
[ 87.362299] [ T1137] nvme_tcp_queue_rq+0xfa3/0x19e0 [nvme_tcp]
[ 87.363334] [ T1137] blk_mq_dispatch_rq_list+0x3e0/0x2400
[ 87.364316] [ T1137] __blk_mq_sched_dispatch_requests+0x20a/0x15d0
[ 87.365378] [ T1137] blk_mq_sched_dispatch_requests+0xa7/0x140
[ 87.366411] [ T1137] blk_mq_run_work_fn+0x135/0x2e0
[ 87.367331] [ T1137] process_one_work+0x8b2/0x15e0
[ 87.368243] [ T1137] worker_thread+0x5fd/0xfe0
[ 87.369107] [ T1137] kthread+0x367/0x460
[ 87.369924] [ T1137] ret_from_fork+0x655/0x9d0
[ 87.370776] [ T1137] ret_from_fork_asm+0x1a/0x30
[ 87.371645] [ T1137]
-> #0 (set->srcu){.+.+}-{0:0}:
[ 87.372966] [ T1137] __lock_acquire+0xe20/0x2440
[ 87.373847] [ T1137] lock_sync+0xbf/0x120
[ 87.374646] [ T1137] __synchronize_srcu+0xe1/0x2f0
[ 87.375530] [ T1137] elevator_switch+0x2bd/0x670
[ 87.376421] [ T1137] elevator_change+0x2e7/0x500
[ 87.377311] [ T1137] elevator_set_none+0xaa/0xf0
[ 87.378203] [ T1137] blk_unregister_queue+0x15e/0x2e0
[ 87.379139] [ T1137] __del_gendisk+0x28b/0xaa0
[ 87.380009] [ T1137] del_gendisk+0x11a/0x1c0
[ 87.380844] [ T1137] nvme_ns_remove+0x331/0x9e0 [nvme_core]
[ 87.381851] [ T1137] nvme_remove_namespaces+0x289/0x3f0 [nvme_core]
[ 87.382970] [ T1137] nvme_do_delete_ctrl+0xf6/0x160 [nvme_core]
[ 87.384028] [ T1137] nvme_delete_ctrl_sync.cold+0x8/0xd [nvme_core]
[ 87.385124] [ T1137] nvme_sysfs_delete+0xb7/0xe0 [nvme_core]
[ 87.386153] [ T1137] kernfs_fop_write_iter+0x3d6/0x5e0
[ 87.387104] [ T1137] vfs_write+0x4b3/0xf40
[ 87.387935] [ T1137] ksys_write+0x112/0x250
[ 87.388756] [ T1137] do_syscall_64+0xdf/0x790
[ 87.389596] [ T1137] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.390592] [ T1137]
other info that might help us debug this:
[ 87.392533] [ T1137] Chain exists of:
set->srcu --> &q->q_usage_counter(io) --> &q->elevator_lock
[ 87.394872] [ T1137] Possible unsafe locking scenario:
[ 87.396268] [ T1137] CPU0 CPU1
[ 87.397169] [ T1137] ---- ----
[ 87.398062] [ T1137] lock(&q->elevator_lock);
[ 87.398873] [ T1137] lock(&q->q_usage_counter(io));
[ 87.400042] [ T1137] lock(&q->elevator_lock);
[ 87.401144] [ T1137] sync(set->srcu);
[ 87.401864] [ T1137]
*** DEADLOCK ***
[ 87.403562] [ T1137] 5 locks held by nvme/1137:
[ 87.404365] [ T1137] #0: ffff8881134a0450 (sb_writers#4){.+.+}-{0:0}, at: ksys_write+0x112/0x250
[ 87.405677] [ T1137] #1: ffff888137b45080 (&of->mutex#2){+.+.}-{4:4}, at: kernfs_fop_write_iter+0x257/0x5e0
[ 87.407118] [ T1137] #2: ffff8881475f82d8 (kn->active#141){++++}-{0:0}, at: sysfs_remove_file_self+0x61/0xb0
[ 87.408549] [ T1137] #3: ffff88812d8641c8 (&set->update_nr_hwq_lock){++++}-{4:4}, at: del_gendisk+0x112/0x1c0
[ 87.410012] [ T1137] #4: ffff88813bebaac8 (&q->elevator_lock){+.+.}-{4:4}, at: elevator_change+0x197/0x500
[ 87.411425] [ T1137]
stack backtrace:
[ 87.412674] [ T1137] CPU: 3 UID: 0 PID: 1137 Comm: nvme Not tainted 7.2.0+ #669 PREEMPT(full)
[ 87.412679] [ T1137] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.17.0-10.fc44 06/10/2025
[ 87.412684] [ T1137] Call Trace:
[ 87.412689] [ T1137] <TASK>
[ 87.412691] [ T1137] dump_stack_lvl+0x6a/0x90
[ 87.412697] [ T1137] print_circular_bug.cold+0x189/0x1eb
[ 87.412704] [ T1137] check_noncircular+0x173/0x1a0
[ 87.412708] [ T1137] __lock_acquire+0xe20/0x2440
[ 87.412712] [ T1137] lock_sync+0xbf/0x120
[ 87.412714] [ T1137] ? __synchronize_srcu+0xc1/0x2f0
[ 87.412717] [ T1137] ? __synchronize_srcu+0xc1/0x2f0
[ 87.412720] [ T1137] __synchronize_srcu+0xe1/0x2f0
[ 87.412723] [ T1137] ? __pfx___synchronize_srcu+0x10/0x10
[ 87.412727] [ T1137] ? ktime_get_mono_fast_ns+0x1f5/0x6a0
[ 87.412733] [ T1137] ? _raw_spin_unlock_irqrestore+0x35/0x60
[ 87.412737] [ T1137] elevator_switch+0x2bd/0x670
[ 87.412740] [ T1137] ? elevator_change+0x197/0x500
[ 87.412742] [ T1137] elevator_change+0x2e7/0x500
[ 87.412744] [ T1137] ? kernfs_put.part.0+0x2ca/0x7d0
[ 87.412747] [ T1137] elevator_set_none+0xaa/0xf0
[ 87.412749] [ T1137] ? __pfx_elevator_set_none+0x10/0x10
[ 87.412751] [ T1137] ? kernfs_put.part.0+0x2f3/0x7d0
[ 87.412754] [ T1137] ? kobject_put+0x62/0x530
[ 87.412759] [ T1137] blk_unregister_queue+0x15e/0x2e0
[ 87.412762] [ T1137] __del_gendisk+0x28b/0xaa0
[ 87.412765] [ T1137] ? down_read+0xbd/0x530
[ 87.412767] [ T1137] ? down_read+0x148/0x530
[ 87.412770] [ T1137] ? __pfx___del_gendisk+0x10/0x10
[ 87.412771] [ T1137] ? __pfx_down_read+0x10/0x10
[ 87.412774] [ T1137] ? up_write+0x24c/0x760
[ 87.412776] [ T1137] ? up_write+0x2f8/0x760
[ 87.412779] [ T1137] del_gendisk+0x11a/0x1c0
[ 87.412782] [ T1137] nvme_ns_remove+0x331/0x9e0 [nvme_core]
[ 87.412802] [ T1137] ? _raw_spin_unlock_irqrestore+0x35/0x60
[ 87.412805] [ T1137] nvme_remove_namespaces+0x289/0x3f0 [nvme_core]
[ 87.412824] [ T1137] ? __pfx_nvme_remove_namespaces+0x10/0x10 [nvme_core]
[ 87.412843] [ T1137] nvme_do_delete_ctrl+0xf6/0x160 [nvme_core]
[ 87.412863] [ T1137] nvme_delete_ctrl_sync.cold+0x8/0xd [nvme_core]
[ 87.412882] [ T1137] nvme_sysfs_delete+0xb7/0xe0 [nvme_core]
[ 87.412901] [ T1137] ? __pfx_sysfs_kf_write+0x10/0x10
[ 87.412903] [ T1137] kernfs_fop_write_iter+0x3d6/0x5e0
[ 87.412907] [ T1137] ? __pfx_kernfs_fop_write_iter+0x10/0x10
[ 87.412909] [ T1137] vfs_write+0x4b3/0xf40
[ 87.412913] [ T1137] ? __pfx_vfs_write+0x10/0x10
[ 87.412915] [ T1137] ? __x64_sys_openat+0x10a/0x210
[ 87.412917] [ T1137] ? __pfx___x64_sys_openat+0x10/0x10
[ 87.412920] [ T1137] ? do_syscall_64+0x1ec/0x790
[ 87.412923] [ T1137] ? trace_hardirqs_on_prepare+0x139/0x180
[ 87.412931] [ T1137] ? lockdep_hardirqs_on+0x8c/0x130
[ 87.412933] [ T1137] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.412935] [ T1137] ? do_syscall_64+0x20a/0x790
[ 87.412939] [ T1137] ksys_write+0x112/0x250
[ 87.412941] [ T1137] ? __pfx_ksys_write+0x10/0x10
[ 87.412945] [ T1137] do_syscall_64+0xdf/0x790
[ 87.412949] [ T1137] ? fput_close_sync+0xda/0x1b0
[ 87.412953] [ T1137] ? __pfx_fput_close_sync+0x10/0x10
[ 87.412955] [ T1137] ? do_raw_spin_unlock+0x55/0x230
[ 87.412958] [ T1137] ? rcu_is_watching+0x11/0xb0
[ 87.412967] [ T1137] ? do_syscall_64+0x1ec/0x790
[ 87.412969] [ T1137] ? trace_hardirqs_on_prepare+0x139/0x180
[ 87.412971] [ T1137] ? lockdep_hardirqs_on+0x8c/0x130
[ 87.412973] [ T1137] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.412975] [ T1137] ? do_syscall_64+0x20a/0x790
[ 87.412977] [ T1137] ? __pfx_ksys_read+0x10/0x10
[ 87.412979] [ T1137] ? do_sys_openat2+0xff/0x170
[ 87.412981] [ T1137] ? __pfx_fput_close_sync+0x10/0x10
[ 87.412983] [ T1137] ? rcu_is_watching+0x11/0xb0
[ 87.412986] [ T1137] ? do_syscall_64+0x1ec/0x790
[ 87.412988] [ T1137] ? trace_hardirqs_on_prepare+0x139/0x180
[ 87.412990] [ T1137] ? lockdep_hardirqs_on+0x8c/0x130
[ 87.412992] [ T1137] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.412994] [ T1137] ? do_syscall_64+0x20a/0x790
[ 87.412996] [ T1137] ? rcu_is_watching+0x11/0xb0
[ 87.412999] [ T1137] ? __x64_sys_openat+0x10a/0x210
[ 87.413002] [ T1137] ? __pfx___x64_sys_openat+0x10/0x10
[ 87.413004] [ T1137] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.413006] [ T1137] ? rcu_is_watching+0x11/0xb0
[ 87.413009] [ T1137] ? do_syscall_64+0x1ec/0x790
[ 87.413011] [ T1137] ? trace_hardirqs_on_prepare+0x139/0x180
[ 87.413013] [ T1137] ? lockdep_hardirqs_on+0x8c/0x130
[ 87.413015] [ T1137] ? do_syscall_64+0x20a/0x790
[ 87.413017] [ T1137] ? entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.413019] [ T1137] ? rcu_is_watching+0x11/0xb0
[ 87.413022] [ T1137] ? trace_hardirqs_on+0x14/0x190
[ 87.413023] [ T1137] ? preempt_count_add+0x7f/0x190
[ 87.413028] [ T1137] ? do_syscall_64+0x5d/0x790
[ 87.413030] [ T1137] ? do_syscall_64+0x8d/0x790
[ 87.413032] [ T1137] ? irqentry_exit+0xfc/0x810
[ 87.413035] [ T1137] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[ 87.413037] [ T1137] RIP: 0033:0x7fa87169008e
[ 87.413040] [ T1137] Code: 4d 89 d8 e8 94 bd 00 00 4c 8b 5d f8 41 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 11 c9 c3 0f 1f 80 00 00 00 00 48 8b 45 10 0f 05 <c9> c3 83 e2 39 83 fa 08 75 e7 e8 03 ff ff ff 0f 1f 00 f3 0f 1e fa
[ 87.413042] [ T1137] RSP: 002b:00007ffee438c910 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[ 87.413049] [ T1137] RAX: ffffffffffffffda RBX: 00007fa871865006 RCX: 00007fa87169008e
[ 87.413051] [ T1137] RDX: 0000000000000001 RSI: 00007fa871865006 RDI: 0000000000000003
[ 87.413053] [ T1137] RBP: 00007ffee438c920 R08: 0000000000000000 R09: 0000000000000000
[ 87.413054] [ T1137] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000010ade770
[ 87.413055] [ T1137] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000010adef80
[ 87.413059] [ T1137] </TASK>
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 5:44 ` Shin'ichiro Kawasaki
@ 2026-08-25 6:25 ` Hillf Danton
2026-08-25 6:45 ` Hillf Danton
2026-08-25 13:08 ` Shin'ichiro Kawasaki
2 siblings, 0 replies; 28+ messages in thread
From: Hillf Danton @ 2026-08-25 6:25 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: Eric Dumazet, syzbot, Nilay Shroff, Keith Busch, boqun,
linux-kernel, netdev, peterz, syzkaller-bugs
On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
> On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> >
> > I think 19bdb70c77d3 should be reverted.
>
> Just reverting the commit will reintroduce the other lockdep WARN that the
> commit addressed. I hope to have another fix to avoid the WARN.
>
I do not think you know the root cause of that lockdep warn, so reverting
19bdb70c77d3 is the right thing to do because of [11, 12].
[11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
[12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 5:44 ` Shin'ichiro Kawasaki
2026-08-25 6:25 ` Hillf Danton
@ 2026-08-25 6:45 ` Hillf Danton
2026-08-25 13:26 ` Shin'ichiro Kawasaki
2026-08-25 13:08 ` Shin'ichiro Kawasaki
2 siblings, 1 reply; 28+ messages in thread
From: Hillf Danton @ 2026-08-25 6:45 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: Eric Dumazet, syzbot, Nilay Shroff, Keith Busch, boqun,
linux-kernel, netdev, peterz, syzkaller-bugs
On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
> On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> >
> > I think 19bdb70c77d3 should be reverted.
>
> Just reverting the commit will reintroduce the other lockdep WARN that the
> commit addressed. I hope to have another fix to avoid the WARN.
>
I do not think you know the root cause of that lockdep warn, so reverting
19bdb70c77d3 is the right thing to do because of [11, 12].
[11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
[12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@sina.com/
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 6:45 ` Hillf Danton
@ 2026-08-25 13:26 ` Shin'ichiro Kawasaki
2026-08-25 13:53 ` Eric Dumazet
2026-08-26 3:06 ` Hillf Danton
0 siblings, 2 replies; 28+ messages in thread
From: Shin'ichiro Kawasaki @ 2026-08-25 13:26 UTC (permalink / raw)
To: Hillf Danton
Cc: Eric Dumazet, syzbot, Nilay Shroff, Keith Busch, boqun,
linux-kernel, netdev, peterz, syzkaller-bugs
On Aug 25, 2026 / 14:45, Hillf Danton wrote:
> On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
> > On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> > >
> > > I think 19bdb70c77d3 should be reverted.
> >
> > Just reverting the commit will reintroduce the other lockdep WARN that the
> > commit addressed. I hope to have another fix to avoid the WARN.
> >
> I do not think you know the root cause of that lockdep warn, so reverting
> 19bdb70c77d3 is the right thing to do because of [11, 12].
>
> [11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
> [12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
> https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@sina.com/
I took a look in the commit [11] and the discussion [12], but couldn't follow
why the commit 19bdb70c77d3 should be reverted. Could you elaborate a bit more
about the reason you suggest the revert?
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 13:26 ` Shin'ichiro Kawasaki
@ 2026-08-25 13:53 ` Eric Dumazet
2026-08-25 14:27 ` Eric Dumazet
2026-08-26 3:06 ` Hillf Danton
1 sibling, 1 reply; 28+ messages in thread
From: Eric Dumazet @ 2026-08-25 13:53 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: Hillf Danton, syzbot, Nilay Shroff, Keith Busch, boqun,
linux-kernel, netdev, peterz, syzkaller-bugs
On Tue, Aug 25, 2026 at 3:26 PM Shin'ichiro Kawasaki
<shinichiro.kawasaki@wdc.com> wrote:
>
> On Aug 25, 2026 / 14:45, Hillf Danton wrote:
> > On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
> > > On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> > > >
> > > > I think 19bdb70c77d3 should be reverted.
> > >
> > > Just reverting the commit will reintroduce the other lockdep WARN that the
> > > commit addressed. I hope to have another fix to avoid the WARN.
> > >
> > I do not think you know the root cause of that lockdep warn, so reverting
> > 19bdb70c77d3 is the right thing to do because of [11, 12].
> >
> > [11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
> > [12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
> > https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@sina.com/
>
> I took a look in the commit [11] and the discussion [12], but couldn't follow
> why the commit 19bdb70c77d3 should be reverted. Could you elaborate a bit more
> about the reason you suggest the revert?
I think you missed one problem in lib/once.c
Revert commit e8eef69a99f1 (or restore once_disable_jump(once_key,
mod) inside __do_once_sleepable_done())
so static_branch_disable() is never called synchronously under caller locks.
Previously, once_disable_jump() deferred static_branch_disable() to a
worker thread via schedule_work().
Commit e8eef69a99f1 made it run synchronously in the caller's context.
Because __inet_hash_connect() is called under lock_sock(sk), calling
static_branch_disable() directly inside DO_ONCE_SLEEPABLE() takes
cpus_read_lock() (cpu_hotplug_lock) while holding lock_sock(sk).
This created the bogus lock dependency sk_lock -> cpu_hotplug_lock.
Every other storage/networking client (sunrpc, nbd, cifs, iscsi_tcp,
rxe, siw) uses static lockdep keys (static struct lock_class_key
...[2]) without issue.
Use my pending TCP patch, which is a no brainer :
https://lore.kernel.org/netdev/20260825023614.1228551-1-edumazet@google.com/
Revert 19bdb70c77d3 in drivers/nvme/host/tcp.c : Restore static
lockdep keys nvme_tcp_sk_key[2] and nvme_tcp_slock_key[2].
And we should be good.
If you think each nvme-tcp socket MUST have its own LOCKDEP class,
please elaborate, because I have no idea
why this would be needed.
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 13:53 ` Eric Dumazet
@ 2026-08-25 14:27 ` Eric Dumazet
2026-08-26 2:23 ` Shin'ichiro Kawasaki
0 siblings, 1 reply; 28+ messages in thread
From: Eric Dumazet @ 2026-08-25 14:27 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: Hillf Danton, syzbot, Nilay Shroff, Keith Busch, boqun,
linux-kernel, netdev, peterz, syzkaller-bugs
On Tue, Aug 25, 2026 at 3:53 PM Eric Dumazet <edumazet@google.com> wrote:
>
> On Tue, Aug 25, 2026 at 3:26 PM Shin'ichiro Kawasaki
> <shinichiro.kawasaki@wdc.com> wrote:
> >
> > On Aug 25, 2026 / 14:45, Hillf Danton wrote:
> > > On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
> > > > On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> > > > >
> > > > > I think 19bdb70c77d3 should be reverted.
> > > >
> > > > Just reverting the commit will reintroduce the other lockdep WARN that the
> > > > commit addressed. I hope to have another fix to avoid the WARN.
> > > >
> > > I do not think you know the root cause of that lockdep warn, so reverting
> > > 19bdb70c77d3 is the right thing to do because of [11, 12].
> > >
> > > [11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
> > > [12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
> > > https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@sina.com/
> >
> > I took a look in the commit [11] and the discussion [12], but couldn't follow
> > why the commit 19bdb70c77d3 should be reverted. Could you elaborate a bit more
> > about the reason you suggest the revert?
>
> I think you missed one problem in lib/once.c
>
> Revert commit e8eef69a99f1 (or restore once_disable_jump(once_key,
> mod) inside __do_once_sleepable_done())
> so static_branch_disable() is never called synchronously under caller locks.
>
> Previously, once_disable_jump() deferred static_branch_disable() to a
> worker thread via schedule_work().
>
> Commit e8eef69a99f1 made it run synchronously in the caller's context.
> Because __inet_hash_connect() is called under lock_sock(sk), calling
> static_branch_disable() directly inside DO_ONCE_SLEEPABLE() takes
> cpus_read_lock() (cpu_hotplug_lock) while holding lock_sock(sk).
>
> This created the bogus lock dependency sk_lock -> cpu_hotplug_lock.
>
> Every other storage/networking client (sunrpc, nbd, cifs, iscsi_tcp,
> rxe, siw) uses static lockdep keys (static struct lock_class_key
> ...[2]) without issue.
I sent the revert request for review :
https://lore.kernel.org/lkml/20260825142515.1965654-1-edumazet@google.com/T/#u
>
> Use my pending TCP patch, which is a no brainer :
> https://lore.kernel.org/netdev/20260825023614.1228551-1-edumazet@google.com/
>
> Revert 19bdb70c77d3 in drivers/nvme/host/tcp.c : Restore static
> lockdep keys nvme_tcp_sk_key[2] and nvme_tcp_slock_key[2].
>
> And we should be good.
>
> If you think each nvme-tcp socket MUST have its own LOCKDEP class,
> please elaborate, because I have no idea
> why this would be needed.
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 14:27 ` Eric Dumazet
@ 2026-08-26 2:23 ` Shin'ichiro Kawasaki
2026-08-27 12:31 ` Hillf Danton
0 siblings, 1 reply; 28+ messages in thread
From: Shin'ichiro Kawasaki @ 2026-08-26 2:23 UTC (permalink / raw)
To: Eric Dumazet
Cc: Hillf Danton, syzbot, Nilay Shroff, Keith Busch, boqun,
linux-kernel, netdev, peterz, syzkaller-bugs
On Aug 25, 2026 / 16:27, Eric Dumazet wrote:
> On Tue, Aug 25, 2026 at 3:53 PM Eric Dumazet <edumazet@google.com> wrote:
> >
> > On Tue, Aug 25, 2026 at 3:26 PM Shin'ichiro Kawasaki
> > <shinichiro.kawasaki@wdc.com> wrote:
> > >
> > > On Aug 25, 2026 / 14:45, Hillf Danton wrote:
> > > > On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
> > > > > On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> > > > > >
> > > > > > I think 19bdb70c77d3 should be reverted.
> > > > >
> > > > > Just reverting the commit will reintroduce the other lockdep WARN that the
> > > > > commit addressed. I hope to have another fix to avoid the WARN.
> > > > >
> > > > I do not think you know the root cause of that lockdep warn, so reverting
> > > > 19bdb70c77d3 is the right thing to do because of [11, 12].
> > > >
> > > > [11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
> > > > [12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
> > > > https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@sina.com/
> > >
> > > I took a look in the commit [11] and the discussion [12], but couldn't follow
> > > why the commit 19bdb70c77d3 should be reverted. Could you elaborate a bit more
> > > about the reason you suggest the revert?
> >
> > I think you missed one problem in lib/once.c
> >
> > Revert commit e8eef69a99f1 (or restore once_disable_jump(once_key,
> > mod) inside __do_once_sleepable_done())
> > so static_branch_disable() is never called synchronously under caller locks.
> >
> > Previously, once_disable_jump() deferred static_branch_disable() to a
> > worker thread via schedule_work().
> >
> > Commit e8eef69a99f1 made it run synchronously in the caller's context.
> > Because __inet_hash_connect() is called under lock_sock(sk), calling
> > static_branch_disable() directly inside DO_ONCE_SLEEPABLE() takes
> > cpus_read_lock() (cpu_hotplug_lock) while holding lock_sock(sk).
> >
> > This created the bogus lock dependency sk_lock -> cpu_hotplug_lock.
> >
> > Every other storage/networking client (sunrpc, nbd, cifs, iscsi_tcp,
> > rxe, siw) uses static lockdep keys (static struct lock_class_key
> > ...[2]) without issue.
>
> I sent the revert request for review :
> https://lore.kernel.org/lkml/20260825142515.1965654-1-edumazet@google.com/T/#u
Thank you for the clarification. Now I have better understanding.
When I looked at the lock dependency chain among six locks below, I assumed
that any of the dependencies could not be cut.
set->srcu -> sk_lock -> cpu_hotplug_lock -> fs_reclaim -> q_usage_counter -> elevator_lock -> set->srcu
So I thought that the idea to introduce the dynamic lockdep key for nvme-tcp
sk_lock instances would be the only one solution. But you pointed out that the
dependency sk_lock -> cpu_hotplug_lock can be cut by reverting the commit
e8eef69a99f1.
I did trial and confirmed that your suggestion works. With the kerenl v7.2 +
revert 19bdb70c77d3 + revert e8eef69a99f1, I confirmed the blktests test case
nvme/005 passed with tcp transport. The lockdep WARN due to the six locks goes
away. Great :)
Assuming e8eef69a99f1 will be reverted, I agree to revert 19bdb70c77d3 also.
>
> >
> > Use my pending TCP patch, which is a no brainer :
> > https://lore.kernel.org/netdev/20260825023614.1228551-1-edumazet@google.com/
IIUC, this patch uses GFP_ATOMIC to cut the dependency sk_lock -> fs_reclaim.
I did another trial: using the kerenl v7.2 + revert 19bdb70c77d3 + the TCP patch
"tcp: use GFP_ATOMIC in tcp_send_active_reset()", I still observed the blktests
test case nvme/005 failed with the lockdep WARN due to the six locks. Hmm.
The TCP patch cuts the direct dependency sk_lock -> fs_reclaim, but the depdency
chain I face has indirect dependency between sk_lock and fs_reclaim:
... sk_lock -> cpu_hotplug_lock -> fs_reclaim ...
I think this explains why the TCP patch does not fix the lockdep WARN due to the
six locks.
> >
> > Revert 19bdb70c77d3 in drivers/nvme/host/tcp.c : Restore static
> > lockdep keys nvme_tcp_sk_key[2] and nvme_tcp_slock_key[2].
> >
> > And we should be good.
> >
> > If you think each nvme-tcp socket MUST have its own LOCKDEP class,
> > please elaborate, because I have no idea
> > why this would be needed.
As I noted above, if e8eef69a99f1 will be reverted, I do not have reason to
make nvme-tcp socket have its owy dynamic lockdep key and class. Let me wait
and see how the e8eef69a99f1 revert patch will go. If it goes well, I will
send out the patch to revert 19bdb70c77d3.
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-26 2:23 ` Shin'ichiro Kawasaki
@ 2026-08-27 12:31 ` Hillf Danton
0 siblings, 0 replies; 28+ messages in thread
From: Hillf Danton @ 2026-08-27 12:31 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: Eric Dumazet, syzbot, Nilay Shroff, Keith Busch, boqun,
linux-kernel, netdev, peterz, syzkaller-bugs
On Wed, 26 Aug 2026 11:23:37 +0900 Shin'ichiro Kawasaki wrote:
>On Aug 25, 2026 / 16:27, Eric Dumazet wrote:
>> On Tue, Aug 25, 2026 at 3:53 PM Eric Dumazet <edumazet@google.com> wrote:
>> > I think you missed one problem in lib/once.c
>> >
>> > Revert commit e8eef69a99f1 (or restore once_disable_jump(once_key,
>> > mod) inside __do_once_sleepable_done())
>> > so static_branch_disable() is never called synchronously under caller locks.
>> >
>> > Previously, once_disable_jump() deferred static_branch_disable() to a
>> > worker thread via schedule_work().
>> >
>> > Commit e8eef69a99f1 made it run synchronously in the caller's context.
>> > Because __inet_hash_connect() is called under lock_sock(sk), calling
>> > static_branch_disable() directly inside DO_ONCE_SLEEPABLE() takes
>> > cpus_read_lock() (cpu_hotplug_lock) while holding lock_sock(sk).
>> >
>> > This created the bogus lock dependency sk_lock -> cpu_hotplug_lock.
>> >
>> > Every other storage/networking client (sunrpc, nbd, cifs, iscsi_tcp,
>> > rxe, siw) uses static lockdep keys (static struct lock_class_key
>> > ...[2]) without issue.
>>
>> I sent the revert request for review :
>> https://lore.kernel.org/lkml/20260825142515.1965654-1-edumazet@google.com/T/#u
>
> Thank you for the clarification. Now I have better understanding.
>
> When I looked at the lock dependency chain among six locks below, I assumed
> that any of the dependencies could not be cut.
>
> set->srcu -> sk_lock -> cpu_hotplug_lock -> fs_reclaim -> q_usage_counter -> elevator_lock -> set->srcu
>
> So I thought that the idea to introduce the dynamic lockdep key for nvme-tcp
> sk_lock instances would be the only one solution. But you pointed out that the
> dependency sk_lock -> cpu_hotplug_lock can be cut by reverting the commit
> e8eef69a99f1.
>
> I did trial and confirmed that your suggestion works. With the kerenl v7.2 +
> revert 19bdb70c77d3 + revert e8eef69a99f1, I confirmed the blktests test case
> nvme/005 passed with tcp transport. The lockdep WARN due to the six locks goes
> away. Great :)
>
Reverting e8eef69a99f1 alone failed to survive the syzbot test [15].
Nor did Eric's change [16] to lockdep alone [17].
Nor did Eric's change [16] to lockdep after Reverting e8eef69a99f1 [18].
[15] Subject: Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
https://lore.kernel.org/lkml/6a90125e.1d9ded08.62e62.00d0.GAE@google.com/
[16] Subject: [PATCH] locking/lockdep: Invalidate stale class_cache entries for zapped classes
https://lore.kernel.org/lkml/20260824155129.676096-1-edumazet@google.com/
[17] Subject: Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
https://lore.kernel.org/lkml/6a8fa86e.27659fcc.2ceef7.000c.GAE@google.com/
[18] Subject: Re: [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2)
https://lore.kernel.org/lkml/6a8fd74f.4d659fcc.734b4.000c.GAE@google.com/
WTF root cause is Eric attempting to fix?
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 13:26 ` Shin'ichiro Kawasaki
2026-08-25 13:53 ` Eric Dumazet
@ 2026-08-26 3:06 ` Hillf Danton
2026-08-26 4:05 ` Eric Dumazet
1 sibling, 1 reply; 28+ messages in thread
From: Hillf Danton @ 2026-08-26 3:06 UTC (permalink / raw)
To: Shin'ichiro Kawasaki
Cc: Eric Dumazet, syzbot, Nilay Shroff, Keith Busch, boqun,
linux-kernel, netdev, peterz, syzkaller-bugs
On Tue, 25 Aug 2026 22:26:25 +0900 Shin'ichiro Kawasaki wrote:
>On Aug 25, 2026 / 14:45, Hillf Danton wrote:
>> On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
>> > On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
>> > >
>> > > I think 19bdb70c77d3 should be reverted.
>> >
>> > Just reverting the commit will reintroduce the other lockdep WARN that the
>> > commit addressed. I hope to have another fix to avoid the WARN.
>> >
>> I do not think you know the root cause of that lockdep warn, so reverting
>> 19bdb70c77d3 is the right thing to do because of [11, 12].
>>
>> [11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
>> [12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
>> https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@sina.com/
>
> I took a look in the commit [11] and the discussion [12], but couldn't follow
> why the commit 19bdb70c77d3 should be reverted. Could you elaborate a bit more
> about the reason you suggest the revert?
>
The Fixes tag in d532cddb6c60 proves Eric delivered a HBC, half baked croissant,
to lore. And the nvme-tcp tucked in the HBC hints Eric copied something from
somewhere. Finally the absence of ffa1e7ada456 in 19bdb70c77d3 proves it is
worse than a HBC. Clear dude? Or go to read [12] again?
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-26 3:06 ` Hillf Danton
@ 2026-08-26 4:05 ` Eric Dumazet
2026-08-26 10:27 ` Hillf Danton
2026-08-28 9:00 ` Hillf Danton
0 siblings, 2 replies; 28+ messages in thread
From: Eric Dumazet @ 2026-08-26 4:05 UTC (permalink / raw)
To: Hillf Danton
Cc: Shin'ichiro Kawasaki, syzbot, Nilay Shroff, Keith Busch,
boqun, linux-kernel, netdev, peterz, syzkaller-bugs
On Wed, Aug 26, 2026 at 5:06 AM Hillf Danton <hdanton@sina.com> wrote:
>
> On Tue, 25 Aug 2026 22:26:25 +0900 Shin'ichiro Kawasaki wrote:
> >On Aug 25, 2026 / 14:45, Hillf Danton wrote:
> >> On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
> >> > On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
> >> > >
> >> > > I think 19bdb70c77d3 should be reverted.
> >> >
> >> > Just reverting the commit will reintroduce the other lockdep WARN that the
> >> > commit addressed. I hope to have another fix to avoid the WARN.
> >> >
> >> I do not think you know the root cause of that lockdep warn, so reverting
> >> 19bdb70c77d3 is the right thing to do because of [11, 12].
> >>
> >> [11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
> >> [12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
> >> https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@sina.com/
> >
> > I took a look in the commit [11] and the discussion [12], but couldn't follow
> > why the commit 19bdb70c77d3 should be reverted. Could you elaborate a bit more
> > about the reason you suggest the revert?
> >
> The Fixes tag in d532cddb6c60 proves Eric delivered a HBC, half baked croissant,
> to lore. And the nvme-tcp tucked in the HBC hints Eric copied something from
> somewhere. Finally the absence of ffa1e7ada456 in 19bdb70c77d3 proves it is
> worse than a HBC. Clear dude? Or go to read [12] again?
linux development is iterative, we do not submit a single patch fixing
1000 bugs at once.
I decided to ignore your rants a long time ago, as many others did.
How many bugs did you fix last year?
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-26 4:05 ` Eric Dumazet
@ 2026-08-26 10:27 ` Hillf Danton
2026-08-26 10:49 ` Eric Dumazet
2026-08-28 9:00 ` Hillf Danton
1 sibling, 1 reply; 28+ messages in thread
From: Hillf Danton @ 2026-08-26 10:27 UTC (permalink / raw)
To: Eric Dumazet
Cc: Shin'ichiro Kawasaki, syzbot, Nilay Shroff, Keith Busch,
boqun, linux-kernel, netdev, peterz, syzkaller-bugs
On Wed, 26 Aug 2026 06:05:15 +0200 Eric Dumazet wrote:
>On Wed, Aug 26, 2026 at 5:06 AM Hillf Danton <hdanton@sina.com> wrote:
>> On Tue, 25 Aug 2026 22:26:25 +0900 Shin'ichiro Kawasaki wrote:
>> >On Aug 25, 2026 / 14:45, Hillf Danton wrote:
>> >> On Tue, 25 Aug 2026 14:44:35 +0900 Shin'ichiro Kawasaki wrote:
>> >> > On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
>> >> > >
>> >> > > I think 19bdb70c77d3 should be reverted.
>> >> >
>> >> > Just reverting the commit will reintroduce the other lockdep WARN that the
>> >> > commit addressed. I hope to have another fix to avoid the WARN.
>> >> >
>> >> I do not think you know the root cause of that lockdep warn, so reverting
>> >> 19bdb70c77d3 is the right thing to do because of [11, 12].
>> >>
>> >> [11] ffa1e7ada456 ("block: Make request_queue lockdep splats show up earlier")
>> >> [12] Subject: Re: [PATCH] nbd: don't warn when reclassifying a busy socket lock
>> >> https://lore.kernel.org/lkml/20260816014906.1149-1-hdanton@sina.com/
>> >
>> > I took a look in the commit [11] and the discussion [12], but couldn't follow
>> > why the commit 19bdb70c77d3 should be reverted. Could you elaborate a bit more
>> > about the reason you suggest the revert?
>> >
>> The Fixes tag in d532cddb6c60 proves Eric delivered a HBC, half baked croissant,
>> to lore. And the nvme-tcp tucked in the HBC hints Eric copied something from
>> somewhere. Finally the absence of ffa1e7ada456 in 19bdb70c77d3 proves it is
>> worse than a HBC. Clear dude? Or go to read [12] again?
>
> linux development is iterative, we do not submit a single patch fixing
> 1000 bugs at once.
>
The iterative word fails to justify you can submit any fix before understanding
the root cause.
> I decided to ignore your rants a long time ago, as many others did.
>
Your HBC forced you to quiese instead just like the ostrich burying his head
in sand.
> How many bugs did you fix last year?
More than 150 [13].
[13] Subject: Re: some works in 2025
https://lore.kernel.org/lkml/20251112225650.9224-1-hdanton@sina.com/
^ permalink raw reply [flat|nested] 28+ messages in thread* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-26 10:27 ` Hillf Danton
@ 2026-08-26 10:49 ` Eric Dumazet
2026-08-26 11:49 ` Hillf Danton
0 siblings, 1 reply; 28+ messages in thread
From: Eric Dumazet @ 2026-08-26 10:49 UTC (permalink / raw)
To: Hillf Danton
Cc: Shin'ichiro Kawasaki, syzbot, Nilay Shroff, Keith Busch,
boqun, linux-kernel, netdev, peterz, syzkaller-bugs
On Wed, Aug 26, 2026 at 12:27 PM Hillf Danton <hdanton@sina.com> wrote:
>
> On Wed, 26 Aug 2026 06:05:15 +0200 Eric Dumazet wrote:
> > How many bugs did you fix last year?
>
> More than 150 [13].
Pure hallucination.
$ git log --author "Hillf Danton" --oneline --since 1year | wc -l
0
Lets compare to some real numbers.
$ git log --author "Eric Dumazet" --oneline --since 1year | wc -l
550
Harassing a maintainer is probably not a good thing, I wish you luck.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-26 10:49 ` Eric Dumazet
@ 2026-08-26 11:49 ` Hillf Danton
0 siblings, 0 replies; 28+ messages in thread
From: Hillf Danton @ 2026-08-26 11:49 UTC (permalink / raw)
To: Eric Dumazet
Cc: Shin'ichiro Kawasaki, syzbot, Nilay Shroff, Keith Busch,
boqun, linux-kernel, netdev, peterz, syzkaller-bugs
On Wed, 26 Aug 2026 12:49:36 +0200 Eric Dumazet wrote:
> On Wed, Aug 26, 2026 at 12:27 PM Hillf Danton <hdanton@sina.com> wrote:
> > On Wed, 26 Aug 2026 06:05:15 +0200 Eric Dumazet wrote:
> > > How many bugs did you fix last year?
> >
> > More than 150 [13].
>
> Pure hallucination.
>
> $ git log --author "Hillf Danton" --oneline --since 1year | wc -l
> 0
>
Before it is proved that linux can make the earth a better place for
everyone, who cares LPC/Unix for example?
> Lets compare to some real numbers.
>
> $ git log --author "Eric Dumazet" --oneline --since 1year | wc -l
> 550
>
HBC in addition to nobrain can also land upstream, no?
How many reverts landed upstream in 2025?
> Harassing a maintainer is probably not a good thing, I wish you luck.
The Harassing word in combination with HBC puts shame on the maintainer's face.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-26 4:05 ` Eric Dumazet
2026-08-26 10:27 ` Hillf Danton
@ 2026-08-28 9:00 ` Hillf Danton
1 sibling, 0 replies; 28+ messages in thread
From: Hillf Danton @ 2026-08-28 9:00 UTC (permalink / raw)
To: Eric Dumazet
Cc: Shin'ichiro Kawasaki, syzbot, Nilay Shroff, Keith Busch,
boqun, linux-kernel, netdev, peterz, syzkaller-bugs
On Wed, 26 Aug 2026 06:05:15 +0200 Eric Dumazet wrote:
>
> I decided to ignore your rants a long time ago, as many others did.
>
Aha another rant chance for showing you the steps to quiese syzbot that
reported deadlock.
[11] Subject: Re: [syzbot] [input?] possible deadlock in tasklet_action_common (2)
https://lore.kernel.org/lkml/6a913c08.4d659fcc.734b4.001b.GAE@google.com/
[12] Subject: Re: [syzbot] [input?] possible deadlock in tasklet_action_common (2)
https://lore.kernel.org/lkml/6a90ef26.27659fcc.2ceef7.0018.GAE@google.com/
This is one of my good works in 2026 in addition to catch your HBCs.
^ permalink raw reply [flat|nested] 28+ messages in thread
* Re: [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler
2026-08-25 5:44 ` Shin'ichiro Kawasaki
2026-08-25 6:25 ` Hillf Danton
2026-08-25 6:45 ` Hillf Danton
@ 2026-08-25 13:08 ` Shin'ichiro Kawasaki
2 siblings, 0 replies; 28+ messages in thread
From: Shin'ichiro Kawasaki @ 2026-08-25 13:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: syzbot, Nilay Shroff, Keith Busch, boqun, hdanton, linux-kernel,
netdev, peterz, syzkaller-bugs
[-- Attachment #1: Type: text/plain, Size: 2077 bytes --]
On Aug 25, 2026 / 14:44, Shin'ichiro Kawasaki wrote:
> On Aug 25, 2026 / 03:50, Eric Dumazet wrote:
[...]
> > I think 19bdb70c77d3 should be reverted.
>
> Just reverting the commit will reintroduce the other lockdep WARN that the
> commit addressed. I hope to have another fix to avoid the WARN.
>
> >
> > We can change TCP to use sk_gfp_mask(sk, GFP_ATOMIC) instead of
> > gfp_any() in tcp_disconnect()
> >
> > This ensures tcp_disconnect() respects sk->sk_allocation = GFP_ATOMIC
> > and never acquires fs_reclaim under sk_lock.
> >
> > WDYT?
>
> Thanks for the idea. I did a quick trial with the idea.
>
> Step 1:
> I reverted the commit 19bdb70c77d3 from v7.2 kernel, and confirmed that
> the blktests test case nvme/005 for tcp transport recreates the lockdep
> WARN that includes fs_reclaim in its lock chain.
>
> Step 2:
> I created a patch to replace gfp_any() in tcp_disconnect() with GFP_ATOMIC
> [1]. I applied this patch to the v7.2 based kernel that I used in the step 1.
> I ran the test case nvme/005 on this kernel, and observed it still fails
> with the lockdep WARN: fs_reclaim was still included in the lock chain.
>
> I think this is expected, since fs_reclaim dependency comes from CPU hotplug
> bring-up context.
>
> Based on this observation, I'm afraid that using GFP_ATOMIC in tcp_disconnect()
> won't work, unfortunately.
>
> Another approach I can think of is to use sk->sk_destruct hook to unregister
> keys, so that the unregistraion happens after the all in-flight skbs complete.
> I will try this approach.
I created a patch that delay the lockdep key unregstration until sk desctruct,
and attached it to this e-mail. It applies to the recent Linus master branch tip
(git hash 818bebeb63dd). Eric, may I ask your comment on the patch and this fix
approach?
I think this approach will avoid the lockdep that syzbot reported. But I don't
know how to confirm it. Could you do the confimration ? (or let me know how to
do it).
This approach adds some complexity. If anyone has simpler solution, it will be
great.
[-- Attachment #2: 0001-nvme-tcp-unregister-lockdep-keys-at-socket-destructi.patch --]
[-- Type: text/plain, Size: 7235 bytes --]
From 3691427f5e9df338bc21068dfb12f4af00a371e7 Mon Sep 17 00:00:00 2001
From: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
Date: Tue, 25 Aug 2026 17:26:53 +0900
Subject: [PATCH] nvme-tcp: unregister lockdep keys at socket destruction
Commit 19bdb70c77d3 ("nvme-tcp: lockdep: use dynamic lockdep keys per
socket instance") introduced dynamic lockdep keys for nvme-tcp socket
instances. The lockdep keys are unregistered in nvme_tcp_free_queue(),
just after __fput_sync(queue->sock->file) call. However, at this point
still in-flight skbs are there. When the skbs are freed, the socket and
the unregistered lockdep keys can be referenced, which resutls in WARNs
[1].
To avoid the WARN, keep the lockdep keys alive until the socket is
destroyed. Allocate the keys separately from struct nvme_tcp_queue and
replace the socket's sk_destruct callback with an NVMe/TCP wrapper. The
wrapper invokes the original destructor and queues work to unregister
and free the keys in process context, since socket destruction can run
in softirq context.
Hold an explicit module reference until the deferred work completes so
that both the destructor and work callback remain valid.
[1] https://lore.kernel.org/netdev/CANn89i+wnTLC==UnXCpjsS4YxvEfhe5oK0N7fttbqr1zKyqdug@mail.gmail.com/
Fixes: 19bdb70c77d3 ("nvme-tcp: lockdep: use dynamic lockdep keys per socket instance")
Signed-off-by: Shin'ichiro Kawasaki <shinichiro.kawasaki@wdc.com>
---
drivers/nvme/host/tcp.c | 117 +++++++++++++++++++++++++++++-----------
1 file changed, 86 insertions(+), 31 deletions(-)
diff --git a/drivers/nvme/host/tcp.c b/drivers/nvme/host/tcp.c
index 5fda9661bdb7..645913edf1f4 100644
--- a/drivers/nvme/host/tcp.c
+++ b/drivers/nvme/host/tcp.c
@@ -144,11 +144,6 @@ struct nvme_tcp_queue {
void (*state_change)(struct sock *);
void (*data_ready)(struct sock *);
void (*write_space)(struct sock *);
-
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- struct lock_class_key nvme_tcp_sk_key;
- struct lock_class_key nvme_tcp_slock_key;
-#endif
};
static DEFINE_MUTEX(nvme_tcp_ctrl_mutex);
@@ -179,35 +174,93 @@ static const struct blk_mq_ops nvme_tcp_admin_mq_ops;
static int nvme_tcp_try_send(struct nvme_tcp_queue *queue);
#ifdef CONFIG_DEBUG_LOCK_ALLOC
+struct nvme_tcp_lockdep_keys {
+ struct lock_class_key sk_key;
+ struct lock_class_key slock_key;
+ void (*sk_destruct)(struct sock *sk);
+ struct work_struct free_work;
+};
+
+static inline struct nvme_tcp_lockdep_keys *nvme_tcp_sock_to_lockdep_keys(struct sock *sk)
+{
+ struct nvme_tcp_lockdep_keys *keys = container_of(
+ sk->sk_lock.dep_map.key, struct nvme_tcp_lockdep_keys, sk_key);
+
+ return keys;
+}
+
+static void nvme_tcp_free_lockdep_keys(struct work_struct *work)
+{
+ struct nvme_tcp_lockdep_keys *keys = container_of(work,
+ struct nvme_tcp_lockdep_keys, free_work);
+
+ lockdep_unregister_key(&keys->sk_key);
+ lockdep_unregister_key(&keys->slock_key);
+ kfree(keys);
+ module_put(THIS_MODULE);
+}
+
+static void nvme_tcp_sk_destruct(struct sock *sk)
+{
+ struct nvme_tcp_lockdep_keys *keys = nvme_tcp_sock_to_lockdep_keys(sk);
+
+ if (keys->sk_destruct)
+ keys->sk_destruct(sk);
+
+ /*
+ * sk_destruct may run in softirq context. Do cleanup in process
+ * context.
+ */
+ queue_work(nvme_tcp_wq, &keys->free_work);
+}
+
+static void nvme_tcp_set_sk_destruct(struct sock *sk)
+{
+ struct nvme_tcp_lockdep_keys *keys = nvme_tcp_sock_to_lockdep_keys(sk);
+
+ keys->sk_destruct = sk->sk_destruct;
+
+ /* keep nvme_tcp loaded until the lockdep key cleanup work completes */
+ __module_get(THIS_MODULE);
+ sk->sk_destruct = nvme_tcp_sk_destruct;
+}
+
/* lockdep can detect a circular dependency of the form
* sk_lock -> mmap_lock (page fault) -> fs locks -> sk_lock
* because dependencies are tracked for both nvme-tcp and user contexts. Using
* a separate class prevents lockdep from conflating nvme-tcp socket use with
* user-space socket API use.
*/
-static void nvme_tcp_reclassify_socket(struct nvme_tcp_queue *queue)
+static int nvme_tcp_reclassify_socket(struct nvme_tcp_queue *queue)
{
+ struct nvme_tcp_lockdep_keys *keys;
struct sock *sk = queue->sock->sk;
if (WARN_ON_ONCE(!sock_allow_reclassification(sk)))
- return;
+ return -EINVAL;
+ if (WARN_ON_ONCE(sk->sk_family != AF_INET && sk->sk_family != AF_INET6))
+ return -EAFNOSUPPORT;
+
+ keys = kzalloc_obj(*keys);
+ if (!keys)
+ return -ENOMEM;
+
+ lockdep_register_key(&keys->sk_key);
+ lockdep_register_key(&keys->slock_key);
+ INIT_WORK(&keys->free_work, nvme_tcp_free_lockdep_keys);
- switch (sk->sk_family) {
- case AF_INET:
+ if (sk->sk_family == AF_INET)
sock_lock_init_class_and_name(sk, "slock-AF_INET-NVME",
- &queue->nvme_tcp_slock_key,
+ &keys->slock_key,
"sk_lock-AF_INET-NVME",
- &queue->nvme_tcp_sk_key);
- break;
- case AF_INET6:
+ &keys->sk_key);
+ else
sock_lock_init_class_and_name(sk, "slock-AF_INET6-NVME",
- &queue->nvme_tcp_slock_key,
+ &keys->slock_key,
"sk_lock-AF_INET6-NVME",
- &queue->nvme_tcp_sk_key);
- break;
- default:
- WARN_ON_ONCE(1);
- }
+ &keys->sk_key);
+
+ return 0;
}
#endif
@@ -1511,11 +1564,6 @@ static void nvme_tcp_free_queue(struct nvme_ctrl *nctrl, int qid)
mutex_destroy(&queue->send_mutex);
mutex_destroy(&queue->queue_lock);
mutex_destroy(&queue->pf_cache_lock);
-
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- lockdep_unregister_key(&queue->nvme_tcp_sk_key);
- lockdep_unregister_key(&queue->nvme_tcp_slock_key);
-#endif
}
static int nvme_tcp_init_connection(struct nvme_tcp_queue *queue)
@@ -1831,6 +1879,9 @@ static int nvme_tcp_alloc_queue(struct nvme_ctrl *nctrl, int qid,
struct nvme_tcp_queue *queue = &ctrl->queues[qid];
int ret, rcv_pdu_size;
struct file *sock_file;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ bool reclassified = false;
+#endif
mutex_init(&queue->queue_lock);
queue->ctrl = ctrl;
@@ -1864,9 +1915,10 @@ static int nvme_tcp_alloc_queue(struct nvme_ctrl *nctrl, int qid,
sk_net_refcnt_upgrade(queue->sock->sk);
#ifdef CONFIG_DEBUG_LOCK_ALLOC
- lockdep_register_key(&queue->nvme_tcp_sk_key);
- lockdep_register_key(&queue->nvme_tcp_slock_key);
- nvme_tcp_reclassify_socket(queue);
+ ret = nvme_tcp_reclassify_socket(queue);
+ if (ret)
+ goto err_sock;
+ reclassified = true;
#endif
/* Single syn retry */
@@ -1960,6 +2012,9 @@ static int nvme_tcp_alloc_queue(struct nvme_ctrl *nctrl, int qid,
if (ret)
goto err_init_connect;
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ nvme_tcp_set_sk_destruct(queue->sock->sk);
+#endif
set_bit(NVME_TCP_Q_ALLOCATED, &queue->flags);
return 0;
@@ -1969,13 +2024,13 @@ static int nvme_tcp_alloc_queue(struct nvme_ctrl *nctrl, int qid,
err_rcv_pdu:
kfree(queue->pdu);
err_sock:
+#ifdef CONFIG_DEBUG_LOCK_ALLOC
+ if (reclassified)
+ nvme_tcp_set_sk_destruct(queue->sock->sk);
+#endif
/* Use sync variant - see nvme_tcp_free_queue() for explanation */
__fput_sync(queue->sock->file);
queue->sock = NULL;
-#ifdef CONFIG_DEBUG_LOCK_ALLOC
- lockdep_unregister_key(&queue->nvme_tcp_sk_key);
- lockdep_unregister_key(&queue->nvme_tcp_slock_key);
-#endif
err_destroy_mutex:
mutex_destroy(&queue->send_mutex);
mutex_destroy(&queue->queue_lock);
--
2.54.0
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2026-08-28 9:01 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2026-03-17 17:33 [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2) syzbot
2026-08-26 19:33 ` syzbot
2026-08-26 22:49 ` Hillf Danton
2026-08-27 3:01 ` [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler syzbot
2026-08-27 6:03 ` [syzbot] [kernfs?] possible deadlock in kernfs_link_sibling (2) Hillf Danton
2026-08-27 6:21 ` syzbot
2026-08-27 8:15 ` Hillf Danton
2026-08-27 10:33 ` syzbot
2026-08-24 15:44 [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler syzbot
2026-08-25 0:29 [PATCH] locking/lockdep: Invalidate stale class_cache entries for zapped classes Hillf Danton
2026-08-25 0:59 ` [syzbot] [net?] WARNING: locking bug in tcp_tsq_handler syzbot
2026-08-25 1:25 ` Hillf Danton
2026-08-25 1:27 ` Eric Dumazet
2026-08-25 1:50 ` Eric Dumazet
2026-08-25 5:44 ` Shin'ichiro Kawasaki
2026-08-25 6:25 ` Hillf Danton
2026-08-25 6:45 ` Hillf Danton
2026-08-25 13:26 ` Shin'ichiro Kawasaki
2026-08-25 13:53 ` Eric Dumazet
2026-08-25 14:27 ` Eric Dumazet
2026-08-26 2:23 ` Shin'ichiro Kawasaki
2026-08-27 12:31 ` Hillf Danton
2026-08-26 3:06 ` Hillf Danton
2026-08-26 4:05 ` Eric Dumazet
2026-08-26 10:27 ` Hillf Danton
2026-08-26 10:49 ` Eric Dumazet
2026-08-26 11:49 ` Hillf Danton
2026-08-28 9:00 ` Hillf Danton
2026-08-25 13:08 ` Shin'ichiro Kawasaki
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®