* [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low
@ 2025-05-27 2:02 Lance Yang
2025-05-27 4:48 ` Waiman Long
0 siblings, 1 reply; 5+ messages in thread
From: Lance Yang @ 2025-05-27 2:02 UTC (permalink / raw)
To: peterz; +Cc: mingo, will, boqun.feng, longman, linux-kernel
From: Lance Yang <lance.yang@linux.dev>
Hi all,
With CONFIG_LOCKDEP on, I got this warning during kernel builds:
[Tue May 27 00:22:59 2025] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
[Tue May 27 00:22:59 2025] turning off the locking correctness validator.
[Tue May 27 00:22:59 2025] CPU: 56 UID: 0 PID: 3362352 Comm: cc1 Kdump: loaded Tainted: G S 6.15.0-rc6 #5 PREEMPT(voluntary)
[Tue May 27 00:22:59 2025] Tainted: [S]=CPU_OUT_OF_SPEC
[Tue May 27 00:22:59 2025] Hardware name: New H3C Technologies Co., Ltd. H3C UniServer R4900 G5/RS35M2C16SB, BIOS 5.69 10/18/2023
[Tue May 27 00:22:59 2025] Call Trace:
[Tue May 27 00:22:59 2025] <TASK>
[Tue May 27 00:22:59 2025] show_stack+0x4d/0x60
[Tue May 27 00:22:59 2025] dump_stack_lvl+0x72/0xa0
[Tue May 27 00:22:59 2025] dump_stack+0x14/0x1a
[Tue May 27 00:22:59 2025] add_chain_cache+0x304/0x330
[Tue May 27 00:22:59 2025] __lock_acquire+0x7d3/0xfd0
[Tue May 27 00:22:59 2025] lock_acquire.part.0+0xb4/0x210
[Tue May 27 00:22:59 2025] ? bad_range+0xa6/0x320
[Tue May 27 00:22:59 2025] ? mark_usage+0x68/0x130
[Tue May 27 00:22:59 2025] lock_acquire+0x62/0x120
[Tue May 27 00:22:59 2025] ? bad_range+0xa6/0x320
[Tue May 27 00:22:59 2025] seqcount_lockdep_reader_access+0x3d/0xa0
[Tue May 27 00:22:59 2025] ? bad_range+0xa6/0x320
[Tue May 27 00:22:59 2025] bad_range+0xa6/0x320
[Tue May 27 00:22:59 2025] ? __kasan_check_write+0x18/0x20
[Tue May 27 00:22:59 2025] expand+0x91/0x3c0
[Tue May 27 00:22:59 2025] ? __del_page_from_free_list+0x82/0x4b0
[Tue May 27 00:22:59 2025] rmqueue_bulk+0x13a/0xc00
[Tue May 27 00:22:59 2025] ? lock_acquire.part.0+0xb4/0x210
[Tue May 27 00:22:59 2025] __rmqueue_pcplist+0x4a7/0x8f0
[Tue May 27 00:22:59 2025] rmqueue_pcplist+0xcc/0x2a0
[Tue May 27 00:22:59 2025] rmqueue.isra.0+0xd26/0x1470
[Tue May 27 00:22:59 2025] ? stack_trace_save+0x96/0xd0
[Tue May 27 00:22:59 2025] ? __pfx_stack_trace_save+0x10/0x10
[Tue May 27 00:22:59 2025] ? stack_depot_save_flags+0x41/0x6a0
[Tue May 27 00:22:59 2025] ? lock_acquire.part.0+0xb4/0x210
[Tue May 27 00:22:59 2025] get_page_from_freelist+0x262/0x11a0
[Tue May 27 00:22:59 2025] ? kasan_save_stack+0x3e/0x50
[Tue May 27 00:22:59 2025] ? kasan_save_stack+0x2f/0x50
[Tue May 27 00:22:59 2025] ? __call_rcu_common.constprop.0+0xc4/0x950
[Tue May 27 00:22:59 2025] ? commit_merge+0x634/0x1100
[Tue May 27 00:22:59 2025] __alloc_frozen_pages_noprof+0x30e/0x6c0
[Tue May 27 00:22:59 2025] ? __pfx___alloc_frozen_pages_noprof+0x10/0x10
[Tue May 27 00:22:59 2025] ? __lock_acquire+0x3dc/0xfd0
[Tue May 27 00:22:59 2025] ? mark_usage+0x68/0x130
[Tue May 27 00:22:59 2025] ? policy_nodemask+0x21d/0x350
[Tue May 27 00:22:59 2025] alloc_pages_mpol+0x163/0x460
[Tue May 27 00:22:59 2025] ? __pfx_alloc_pages_mpol+0x10/0x10
[Tue May 27 00:22:59 2025] ? ___slab_alloc+0xe3/0x10f0
[Tue May 27 00:22:59 2025] ? find_held_lock+0x31/0x90
[Tue May 27 00:22:59 2025] alloc_frozen_pages_noprof+0x4b/0x130
[Tue May 27 00:22:59 2025] allocate_slab+0x23a/0x380
[Tue May 27 00:22:59 2025] ___slab_alloc+0x985/0x10f0
[Tue May 27 00:22:59 2025] ? find_held_lock+0x31/0x90
[Tue May 27 00:22:59 2025] ? xfs_buf_item_init+0x7b/0x660 [xfs]
[Tue May 27 00:22:59 2025] ? xfs_buf_item_init+0x7b/0x660 [xfs]
[Tue May 27 00:22:59 2025] ? lock_release.part.0+0x20/0x60
[Tue May 27 00:22:59 2025] ? fs_reclaim_acquire+0x83/0x120
[Tue May 27 00:22:59 2025] ? xfs_buf_item_init+0x7b/0x660 [xfs]
[Tue May 27 00:22:59 2025] kmem_cache_alloc_noprof+0x1ed/0x430
[Tue May 27 00:22:59 2025] ? kmem_cache_alloc_noprof+0x1ed/0x430
[Tue May 27 00:22:59 2025] xfs_buf_item_init+0x7b/0x660 [xfs]
[Tue May 27 00:22:59 2025] ? xfs_imap_to_bp+0x10b/0x2b0 [xfs]
[Tue May 27 00:22:59 2025] ? __pfx_xfs_buf_read_map+0x10/0x10 [xfs]
[Tue May 27 00:22:59 2025] ? xfs_file_buffered_write+0x14c/0xa50 [xfs]
[Tue May 27 00:22:59 2025] _xfs_trans_bjoin+0x45/0x130 [xfs]
[Tue May 27 00:22:59 2025] xfs_trans_read_buf_map+0x38c/0x840 [xfs]
[Tue May 27 00:22:59 2025] ? __pfx_xfs_trans_read_buf_map+0x10/0x10 [xfs]
[Tue May 27 00:22:59 2025] ? lock_acquire.part.0+0xb4/0x210
[Tue May 27 00:22:59 2025] xfs_imap_to_bp+0x10b/0x2b0 [xfs]
[Tue May 27 00:22:59 2025] ? __pfx_xfs_imap_to_bp+0x10/0x10 [xfs]
[Tue May 27 00:22:59 2025] ? __kasan_check_read+0x15/0x20
[Tue May 27 00:22:59 2025] ? do_raw_spin_unlock+0x5d/0x1f0
[Tue May 27 00:22:59 2025] xfs_inode_item_precommit+0x538/0xc10 [xfs]
[Tue May 27 00:22:59 2025] ? __pfx_xfs_inode_item_precommit+0x10/0x10 [xfs]
[Tue May 27 00:22:59 2025] __xfs_trans_commit+0x2a3/0xba0 [xfs]
[Tue May 27 00:22:59 2025] ? __pfx___xfs_trans_commit+0x10/0x10 [xfs]
[Tue May 27 00:22:59 2025] ? ktime_get_coarse_real_ts64_mg+0x61/0x1d0
[Tue May 27 00:22:59 2025] ? __kasan_check_read+0x15/0x20
[Tue May 27 00:22:59 2025] xfs_trans_commit+0xce/0x150 [xfs]
[Tue May 27 00:22:59 2025] ? xfs_trans_ijoin+0xcf/0x170 [xfs]
[Tue May 27 00:22:59 2025] ? __pfx_xfs_trans_commit+0x10/0x10 [xfs]
[Tue May 27 00:22:59 2025] xfs_vn_update_time+0x1fc/0x440 [xfs]
[Tue May 27 00:22:59 2025] ? __pfx_xfs_vn_update_time+0x10/0x10 [xfs]
[Tue May 27 00:22:59 2025] ? __kasan_check_read+0x15/0x20
[Tue May 27 00:22:59 2025] kiocb_modified+0x1a6/0x240
[Tue May 27 00:22:59 2025] xfs_file_write_checks.constprop.0+0x451/0x860 [xfs]
[Tue May 27 00:22:59 2025] xfs_file_buffered_write+0x14c/0xa50 [xfs]
[Tue May 27 00:22:59 2025] ? __pfx_xfs_file_buffered_write+0x10/0x10 [xfs]
[Tue May 27 00:22:59 2025] ? ovl_other_xattr_get+0xee/0x160 [overlay]
[Tue May 27 00:22:59 2025] ? find_held_lock+0x31/0x90
[Tue May 27 00:22:59 2025] ? __pfx_ovl_other_xattr_get+0x10/0x10 [overlay]
[Tue May 27 00:22:59 2025] ? mark_usage+0x68/0x130
[Tue May 27 00:22:59 2025] xfs_file_write_iter+0x553/0x830 [xfs]
[Tue May 27 00:22:59 2025] do_iter_readv_writev+0x422/0x910
[Tue May 27 00:22:59 2025] ? lock_acquire.part.0+0xb4/0x210
[Tue May 27 00:22:59 2025] ? backing_file_write_iter.part.0+0x4ee/0x7e0
[Tue May 27 00:22:59 2025] ? __pfx_do_iter_readv_writev+0x10/0x10
[Tue May 27 00:22:59 2025] ? selinux_file_permission+0x389/0x470
[Tue May 27 00:22:59 2025] ? lock_is_held_type+0xa8/0x120
[Tue May 27 00:22:59 2025] vfs_iter_write+0x17b/0x7a0
[Tue May 27 00:22:59 2025] backing_file_write_iter.part.0+0x4ee/0x7e0
[Tue May 27 00:22:59 2025] ? ovl_real_file+0x16a/0x1b0 [overlay]
[Tue May 27 00:22:59 2025] backing_file_write_iter+0xc8/0x110
[Tue May 27 00:22:59 2025] ovl_write_iter+0x2cc/0x450 [overlay]
[Tue May 27 00:22:59 2025] ? __pfx_ovl_write_iter+0x10/0x10 [overlay]
[Tue May 27 00:22:59 2025] ? __pfx_ovl_file_end_write+0x10/0x10 [overlay]
[Tue May 27 00:22:59 2025] ? lock_is_held_type+0xa8/0x120
[Tue May 27 00:22:59 2025] vfs_write+0x5c1/0x1050
[Tue May 27 00:22:59 2025] ? __pfx_vfs_write+0x10/0x10
[Tue May 27 00:22:59 2025] ? ktime_get_coarse_real_ts64+0x44/0xd0
[Tue May 27 00:22:59 2025] ? lockdep_hardirqs_on_prepare.part.0+0xa3/0x140
[Tue May 27 00:22:59 2025] ksys_write+0x109/0x200
[Tue May 27 00:22:59 2025] ? __lock_release.isra.0+0x60/0x160
[Tue May 27 00:22:59 2025] ? __pfx_ksys_write+0x10/0x10
[Tue May 27 00:22:59 2025] ? __audit_syscall_entry+0x2ef/0x540
[Tue May 27 00:22:59 2025] ? irqentry_exit_to_user_mode+0x7d/0x290
[Tue May 27 00:22:59 2025] ? irqentry_exit+0x6f/0xa0
[Tue May 27 00:22:59 2025] __x64_sys_write+0x76/0xb0
[Tue May 27 00:22:59 2025] x64_sys_call+0x28a/0x1d70
[Tue May 27 00:22:59 2025] do_syscall_64+0x77/0x180
[Tue May 27 00:22:59 2025] entry_SYSCALL_64_after_hwframe+0x76/0x7e
[Tue May 27 00:22:59 2025] RIP: 0033:0x7f56cbac9687
[Tue May 27 00:22:59 2025] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
[Tue May 27 00:22:59 2025] RSP: 002b:00007ffe65c16880 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
[Tue May 27 00:22:59 2025] RAX: ffffffffffffffda RBX: 00007f56cba39440 RCX: 00007f56cbac9687
[Tue May 27 00:22:59 2025] RDX: 0000000000001000 RSI: 0000000004735f60 RDI: 0000000000000003
[Tue May 27 00:22:59 2025] RBP: 0000000004735f60 R08: 0000000000000000 R09: 0000000000000000
[Tue May 27 00:22:59 2025] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000001000
[Tue May 27 00:22:59 2025] R13: 00000000046ecad0 R14: 00007f56cbc1fe80 R15: 0000000000000028
[Tue May 27 00:22:59 2025] </TASK>
$ cat .config|grep CONFIG_LOCKDEP
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_LOCKDEP=y
CONFIG_LOCKDEP_BITS=15
CONFIG_LOCKDEP_CHAINS_BITS=16
CONFIG_LOCKDEP_STACK_TRACE_BITS=19
CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14
CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12
Is it safe? Or could this be a real locking issue?
Thanks,
Lance
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low
2025-05-27 2:02 [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low Lance Yang
@ 2025-05-27 4:48 ` Waiman Long
2025-05-27 5:33 ` Lance Yang
0 siblings, 1 reply; 5+ messages in thread
From: Waiman Long @ 2025-05-27 4:48 UTC (permalink / raw)
To: Lance Yang, peterz; +Cc: mingo, will, boqun.feng, linux-kernel
On 5/26/25 10:02 PM, Lance Yang wrote:
> From: Lance Yang <lance.yang@linux.dev>
>
> Hi all,
>
> With CONFIG_LOCKDEP on, I got this warning during kernel builds:
>
> [Tue May 27 00:22:59 2025] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
> [Tue May 27 00:22:59 2025] turning off the locking correctness validator.
> [Tue May 27 00:22:59 2025] CPU: 56 UID: 0 PID: 3362352 Comm: cc1 Kdump: loaded Tainted: G S 6.15.0-rc6 #5 PREEMPT(voluntary)
> [Tue May 27 00:22:59 2025] Tainted: [S]=CPU_OUT_OF_SPEC
> [Tue May 27 00:22:59 2025] Hardware name: New H3C Technologies Co., Ltd. H3C UniServer R4900 G5/RS35M2C16SB, BIOS 5.69 10/18/2023
> [Tue May 27 00:22:59 2025] Call Trace:
> [Tue May 27 00:22:59 2025] <TASK>
> [Tue May 27 00:22:59 2025] show_stack+0x4d/0x60
> [Tue May 27 00:22:59 2025] dump_stack_lvl+0x72/0xa0
> [Tue May 27 00:22:59 2025] dump_stack+0x14/0x1a
> [Tue May 27 00:22:59 2025] add_chain_cache+0x304/0x330
> [Tue May 27 00:22:59 2025] __lock_acquire+0x7d3/0xfd0
> [Tue May 27 00:22:59 2025] lock_acquire.part.0+0xb4/0x210
> [Tue May 27 00:22:59 2025] ? bad_range+0xa6/0x320
> [Tue May 27 00:22:59 2025] ? mark_usage+0x68/0x130
> [Tue May 27 00:22:59 2025] lock_acquire+0x62/0x120
> [Tue May 27 00:22:59 2025] ? bad_range+0xa6/0x320
> [Tue May 27 00:22:59 2025] seqcount_lockdep_reader_access+0x3d/0xa0
> [Tue May 27 00:22:59 2025] ? bad_range+0xa6/0x320
> [Tue May 27 00:22:59 2025] bad_range+0xa6/0x320
> [Tue May 27 00:22:59 2025] ? __kasan_check_write+0x18/0x20
> [Tue May 27 00:22:59 2025] expand+0x91/0x3c0
> [Tue May 27 00:22:59 2025] ? __del_page_from_free_list+0x82/0x4b0
> [Tue May 27 00:22:59 2025] rmqueue_bulk+0x13a/0xc00
> [Tue May 27 00:22:59 2025] ? lock_acquire.part.0+0xb4/0x210
> [Tue May 27 00:22:59 2025] __rmqueue_pcplist+0x4a7/0x8f0
> [Tue May 27 00:22:59 2025] rmqueue_pcplist+0xcc/0x2a0
> [Tue May 27 00:22:59 2025] rmqueue.isra.0+0xd26/0x1470
> [Tue May 27 00:22:59 2025] ? stack_trace_save+0x96/0xd0
> [Tue May 27 00:22:59 2025] ? __pfx_stack_trace_save+0x10/0x10
> [Tue May 27 00:22:59 2025] ? stack_depot_save_flags+0x41/0x6a0
> [Tue May 27 00:22:59 2025] ? lock_acquire.part.0+0xb4/0x210
> [Tue May 27 00:22:59 2025] get_page_from_freelist+0x262/0x11a0
> [Tue May 27 00:22:59 2025] ? kasan_save_stack+0x3e/0x50
> [Tue May 27 00:22:59 2025] ? kasan_save_stack+0x2f/0x50
> [Tue May 27 00:22:59 2025] ? __call_rcu_common.constprop.0+0xc4/0x950
> [Tue May 27 00:22:59 2025] ? commit_merge+0x634/0x1100
> [Tue May 27 00:22:59 2025] __alloc_frozen_pages_noprof+0x30e/0x6c0
> [Tue May 27 00:22:59 2025] ? __pfx___alloc_frozen_pages_noprof+0x10/0x10
> [Tue May 27 00:22:59 2025] ? __lock_acquire+0x3dc/0xfd0
> [Tue May 27 00:22:59 2025] ? mark_usage+0x68/0x130
> [Tue May 27 00:22:59 2025] ? policy_nodemask+0x21d/0x350
> [Tue May 27 00:22:59 2025] alloc_pages_mpol+0x163/0x460
> [Tue May 27 00:22:59 2025] ? __pfx_alloc_pages_mpol+0x10/0x10
> [Tue May 27 00:22:59 2025] ? ___slab_alloc+0xe3/0x10f0
> [Tue May 27 00:22:59 2025] ? find_held_lock+0x31/0x90
> [Tue May 27 00:22:59 2025] alloc_frozen_pages_noprof+0x4b/0x130
> [Tue May 27 00:22:59 2025] allocate_slab+0x23a/0x380
> [Tue May 27 00:22:59 2025] ___slab_alloc+0x985/0x10f0
> [Tue May 27 00:22:59 2025] ? find_held_lock+0x31/0x90
> [Tue May 27 00:22:59 2025] ? xfs_buf_item_init+0x7b/0x660 [xfs]
> [Tue May 27 00:22:59 2025] ? xfs_buf_item_init+0x7b/0x660 [xfs]
> [Tue May 27 00:22:59 2025] ? lock_release.part.0+0x20/0x60
> [Tue May 27 00:22:59 2025] ? fs_reclaim_acquire+0x83/0x120
> [Tue May 27 00:22:59 2025] ? xfs_buf_item_init+0x7b/0x660 [xfs]
> [Tue May 27 00:22:59 2025] kmem_cache_alloc_noprof+0x1ed/0x430
> [Tue May 27 00:22:59 2025] ? kmem_cache_alloc_noprof+0x1ed/0x430
> [Tue May 27 00:22:59 2025] xfs_buf_item_init+0x7b/0x660 [xfs]
> [Tue May 27 00:22:59 2025] ? xfs_imap_to_bp+0x10b/0x2b0 [xfs]
> [Tue May 27 00:22:59 2025] ? __pfx_xfs_buf_read_map+0x10/0x10 [xfs]
> [Tue May 27 00:22:59 2025] ? xfs_file_buffered_write+0x14c/0xa50 [xfs]
> [Tue May 27 00:22:59 2025] _xfs_trans_bjoin+0x45/0x130 [xfs]
> [Tue May 27 00:22:59 2025] xfs_trans_read_buf_map+0x38c/0x840 [xfs]
> [Tue May 27 00:22:59 2025] ? __pfx_xfs_trans_read_buf_map+0x10/0x10 [xfs]
> [Tue May 27 00:22:59 2025] ? lock_acquire.part.0+0xb4/0x210
> [Tue May 27 00:22:59 2025] xfs_imap_to_bp+0x10b/0x2b0 [xfs]
> [Tue May 27 00:22:59 2025] ? __pfx_xfs_imap_to_bp+0x10/0x10 [xfs]
> [Tue May 27 00:22:59 2025] ? __kasan_check_read+0x15/0x20
> [Tue May 27 00:22:59 2025] ? do_raw_spin_unlock+0x5d/0x1f0
> [Tue May 27 00:22:59 2025] xfs_inode_item_precommit+0x538/0xc10 [xfs]
> [Tue May 27 00:22:59 2025] ? __pfx_xfs_inode_item_precommit+0x10/0x10 [xfs]
> [Tue May 27 00:22:59 2025] __xfs_trans_commit+0x2a3/0xba0 [xfs]
> [Tue May 27 00:22:59 2025] ? __pfx___xfs_trans_commit+0x10/0x10 [xfs]
> [Tue May 27 00:22:59 2025] ? ktime_get_coarse_real_ts64_mg+0x61/0x1d0
> [Tue May 27 00:22:59 2025] ? __kasan_check_read+0x15/0x20
> [Tue May 27 00:22:59 2025] xfs_trans_commit+0xce/0x150 [xfs]
> [Tue May 27 00:22:59 2025] ? xfs_trans_ijoin+0xcf/0x170 [xfs]
> [Tue May 27 00:22:59 2025] ? __pfx_xfs_trans_commit+0x10/0x10 [xfs]
> [Tue May 27 00:22:59 2025] xfs_vn_update_time+0x1fc/0x440 [xfs]
> [Tue May 27 00:22:59 2025] ? __pfx_xfs_vn_update_time+0x10/0x10 [xfs]
> [Tue May 27 00:22:59 2025] ? __kasan_check_read+0x15/0x20
> [Tue May 27 00:22:59 2025] kiocb_modified+0x1a6/0x240
> [Tue May 27 00:22:59 2025] xfs_file_write_checks.constprop.0+0x451/0x860 [xfs]
> [Tue May 27 00:22:59 2025] xfs_file_buffered_write+0x14c/0xa50 [xfs]
> [Tue May 27 00:22:59 2025] ? __pfx_xfs_file_buffered_write+0x10/0x10 [xfs]
> [Tue May 27 00:22:59 2025] ? ovl_other_xattr_get+0xee/0x160 [overlay]
> [Tue May 27 00:22:59 2025] ? find_held_lock+0x31/0x90
> [Tue May 27 00:22:59 2025] ? __pfx_ovl_other_xattr_get+0x10/0x10 [overlay]
> [Tue May 27 00:22:59 2025] ? mark_usage+0x68/0x130
> [Tue May 27 00:22:59 2025] xfs_file_write_iter+0x553/0x830 [xfs]
> [Tue May 27 00:22:59 2025] do_iter_readv_writev+0x422/0x910
> [Tue May 27 00:22:59 2025] ? lock_acquire.part.0+0xb4/0x210
> [Tue May 27 00:22:59 2025] ? backing_file_write_iter.part.0+0x4ee/0x7e0
> [Tue May 27 00:22:59 2025] ? __pfx_do_iter_readv_writev+0x10/0x10
> [Tue May 27 00:22:59 2025] ? selinux_file_permission+0x389/0x470
> [Tue May 27 00:22:59 2025] ? lock_is_held_type+0xa8/0x120
> [Tue May 27 00:22:59 2025] vfs_iter_write+0x17b/0x7a0
> [Tue May 27 00:22:59 2025] backing_file_write_iter.part.0+0x4ee/0x7e0
> [Tue May 27 00:22:59 2025] ? ovl_real_file+0x16a/0x1b0 [overlay]
> [Tue May 27 00:22:59 2025] backing_file_write_iter+0xc8/0x110
> [Tue May 27 00:22:59 2025] ovl_write_iter+0x2cc/0x450 [overlay]
> [Tue May 27 00:22:59 2025] ? __pfx_ovl_write_iter+0x10/0x10 [overlay]
> [Tue May 27 00:22:59 2025] ? __pfx_ovl_file_end_write+0x10/0x10 [overlay]
> [Tue May 27 00:22:59 2025] ? lock_is_held_type+0xa8/0x120
> [Tue May 27 00:22:59 2025] vfs_write+0x5c1/0x1050
> [Tue May 27 00:22:59 2025] ? __pfx_vfs_write+0x10/0x10
> [Tue May 27 00:22:59 2025] ? ktime_get_coarse_real_ts64+0x44/0xd0
> [Tue May 27 00:22:59 2025] ? lockdep_hardirqs_on_prepare.part.0+0xa3/0x140
> [Tue May 27 00:22:59 2025] ksys_write+0x109/0x200
> [Tue May 27 00:22:59 2025] ? __lock_release.isra.0+0x60/0x160
> [Tue May 27 00:22:59 2025] ? __pfx_ksys_write+0x10/0x10
> [Tue May 27 00:22:59 2025] ? __audit_syscall_entry+0x2ef/0x540
> [Tue May 27 00:22:59 2025] ? irqentry_exit_to_user_mode+0x7d/0x290
> [Tue May 27 00:22:59 2025] ? irqentry_exit+0x6f/0xa0
> [Tue May 27 00:22:59 2025] __x64_sys_write+0x76/0xb0
> [Tue May 27 00:22:59 2025] x64_sys_call+0x28a/0x1d70
> [Tue May 27 00:22:59 2025] do_syscall_64+0x77/0x180
> [Tue May 27 00:22:59 2025] entry_SYSCALL_64_after_hwframe+0x76/0x7e
> [Tue May 27 00:22:59 2025] RIP: 0033:0x7f56cbac9687
> [Tue May 27 00:22:59 2025] Code: 48 89 fa 4c 89 df e8 58 b3 00 00 8b 93 08 03 00 00 59 5e 48 83 f8 fc 74 1a 5b c3 0f 1f 84 00 00 00 00 00 48 8b 44 24 10 0f 05 <5b> c3 0f 1f 80 00 00 00 00 83 e2 39 83 fa 08 75 de e8 23 ff ff ff
> [Tue May 27 00:22:59 2025] RSP: 002b:00007ffe65c16880 EFLAGS: 00000202 ORIG_RAX: 0000000000000001
> [Tue May 27 00:22:59 2025] RAX: ffffffffffffffda RBX: 00007f56cba39440 RCX: 00007f56cbac9687
> [Tue May 27 00:22:59 2025] RDX: 0000000000001000 RSI: 0000000004735f60 RDI: 0000000000000003
> [Tue May 27 00:22:59 2025] RBP: 0000000004735f60 R08: 0000000000000000 R09: 0000000000000000
> [Tue May 27 00:22:59 2025] R10: 0000000000000000 R11: 0000000000000202 R12: 0000000000001000
> [Tue May 27 00:22:59 2025] R13: 00000000046ecad0 R14: 00007f56cbc1fe80 R15: 0000000000000028
> [Tue May 27 00:22:59 2025] </TASK>
>
> $ cat .config|grep CONFIG_LOCKDEP
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_LOCKDEP=y
> CONFIG_LOCKDEP_BITS=15
> CONFIG_LOCKDEP_CHAINS_BITS=16
> CONFIG_LOCKDEP_STACK_TRACE_BITS=19
> CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14
> CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12
>
> Is it safe? Or could this be a real locking issue?
The lock chains store the locking order of nested locks. The default
value of 16 may be too low now as the kernel is becoming more complex in
term of possible nested locking orders. Anyway, I would suggest upping
the CONFIG_LOCKDEP_CHAIN_BITS to 17 or even 18 to prevent this kind of
problem. In fact, the latest RHEL debug kernel sets
CONFIG_LOCKDEP_CHAINS_BITS to 18.
Cheers,
Longman
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low
2025-05-27 4:48 ` Waiman Long
@ 2025-05-27 5:33 ` Lance Yang
2025-05-27 5:53 ` Waiman Long
0 siblings, 1 reply; 5+ messages in thread
From: Lance Yang @ 2025-05-27 5:33 UTC (permalink / raw)
To: Waiman Long, peterz
Cc: mingo, will, boqun.feng, linux-kernel, Lance Yang, Zi Li
Hi Longman,
Thanks for looking into this!
On 2025/5/27 12:48, Waiman Long wrote:
> On 5/26/25 10:02 PM, Lance Yang wrote:
>> From: Lance Yang <lance.yang@linux.dev>
>>
>> Hi all,
>>
>> With CONFIG_LOCKDEP on, I got this warning during kernel builds:
>>
>> [Tue May 27 00:22:59 2025] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
[...]
>>
>> $ cat .config|grep CONFIG_LOCKDEP
>> CONFIG_LOCKDEP_SUPPORT=y
>> CONFIG_LOCKDEP=y
>> CONFIG_LOCKDEP_BITS=15
>> CONFIG_LOCKDEP_CHAINS_BITS=16
>> CONFIG_LOCKDEP_STACK_TRACE_BITS=19
>> CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14
>> CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12
>>
>> Is it safe? Or could this be a real locking issue?
>
> The lock chains store the locking order of nested locks. The default
> value of 16 may be too low now as the kernel is becoming more complex in
> term of possible nested locking orders. Anyway, I would suggest upping
> the CONFIG_LOCKDEP_CHAIN_BITS to 17 or even 18 to prevent this kind of
> problem. In fact, the latest RHEL debug kernel sets
> CONFIG_LOCKDEP_CHAINS_BITS to 18.
Yes, makes sense to me. Bumping it to 18 sounds reasonable as the kernel
is getting more complex in terms of possible nested locking orders. It
uses a bit more memory, but keeping LOCKDEP working is worth it ;)
And if there are no objections, I’d be happy to send a patch making the
change.
Thanks,
Lance
>
> Cheers,
> Longman
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low
2025-05-27 5:33 ` Lance Yang
@ 2025-05-27 5:53 ` Waiman Long
2025-05-27 11:59 ` Lance Yang
0 siblings, 1 reply; 5+ messages in thread
From: Waiman Long @ 2025-05-27 5:53 UTC (permalink / raw)
To: Lance Yang, Waiman Long, peterz
Cc: mingo, will, boqun.feng, linux-kernel, Lance Yang, Zi Li
On 5/27/25 1:33 AM, Lance Yang wrote:
> Hi Longman,
>
> Thanks for looking into this!
>
> On 2025/5/27 12:48, Waiman Long wrote:
>> On 5/26/25 10:02 PM, Lance Yang wrote:
>>> From: Lance Yang <lance.yang@linux.dev>
>>>
>>> Hi all,
>>>
>>> With CONFIG_LOCKDEP on, I got this warning during kernel builds:
>>>
>>> [Tue May 27 00:22:59 2025] BUG: MAX_LOCKDEP_CHAIN_HLOCKS too low!
>
> [...]
>
>>>
>>> $ cat .config|grep CONFIG_LOCKDEP
>>> CONFIG_LOCKDEP_SUPPORT=y
>>> CONFIG_LOCKDEP=y
>>> CONFIG_LOCKDEP_BITS=15
>>> CONFIG_LOCKDEP_CHAINS_BITS=16
>>> CONFIG_LOCKDEP_STACK_TRACE_BITS=19
>>> CONFIG_LOCKDEP_STACK_TRACE_HASH_BITS=14
>>> CONFIG_LOCKDEP_CIRCULAR_QUEUE_BITS=12
>>>
>>> Is it safe? Or could this be a real locking issue?
>>
>> The lock chains store the locking order of nested locks. The default
>> value of 16 may be too low now as the kernel is becoming more complex
>> in term of possible nested locking orders. Anyway, I would suggest
>> upping the CONFIG_LOCKDEP_CHAIN_BITS to 17 or even 18 to prevent this
>> kind of problem. In fact, the latest RHEL debug kernel sets
>> CONFIG_LOCKDEP_CHAINS_BITS to 18.
>
> Yes, makes sense to me. Bumping it to 18 sounds reasonable as the kernel
> is getting more complex in terms of possible nested locking orders. It
> uses a bit more memory, but keeping LOCKDEP working is worth it ;)
>
> And if there are no objections, I’d be happy to send a patch making the
> change.
MAX_LOCKDEP_CHAIN_HLOCKS is composed of 2 parts - (1 <<
MAX_LOCKDEP_CHAINS_BITS) and AVG_LOCKDEP_CHAIN_DEPTH (5). I believe that
the average lock chain length is probably bigger than 5 now. We will
have to check the /proc/lockdep file to figure out if we should increase
it as well. Anyway, I think we should increase
CONFIG_LOCKDEP_CHAINS_BITS to at least 17, those we may still hit the
"MAX_LOCKDEP_CHAIN_HLOCKS too low" if we run a variety of different
workloads without reboot.
Cheers,
Longman
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low
2025-05-27 5:53 ` Waiman Long
@ 2025-05-27 11:59 ` Lance Yang
0 siblings, 0 replies; 5+ messages in thread
From: Lance Yang @ 2025-05-27 11:59 UTC (permalink / raw)
To: Waiman Long, peterz
Cc: mingo, will, boqun.feng, linux-kernel, Lance Yang, Zi Li
On 2025/5/27 13:53, Waiman Long wrote:
> MAX_LOCKDEP_CHAIN_HLOCKS is composed of 2 parts - (1 <<
> MAX_LOCKDEP_CHAINS_BITS) and AVG_LOCKDEP_CHAIN_DEPTH (5). I believe that
> the average lock chain length is probably bigger than 5 now. We will
> have to check the /proc/lockdep file to figure out if we should increase
> it as well. Anyway, I think we should increase
Yeah, just checked `/proc/lockdep_stats` on my machine, and it shows
'max locking depth: 30':
$ cat /proc/lockdep_stats
lock-classes: 2074 [max: 8192]
direct dependencies: 22596 [max: 32768]
indirect dependencies: 124267
all direct dependencies: 527384
dependency chains: 51354 [max: 65536]
dependency chain hlocks used: 327679 [max: 327680]
dependency chain hlocks lost: 1
in-hardirq chains: 209
in-softirq chains: 1068
in-process chains: 50076
stack-trace entries: 306274 [max: 524288]
number of stack traces: 11921
number of stack hash chains: 8482
combined max dependencies: 2651851138
hardirq-safe locks: 85
hardirq-unsafe locks: 1301
softirq-safe locks: 284
softirq-unsafe locks: 1123
irq-safe locks: 303
irq-unsafe locks: 1301
hardirq-read-safe locks: 4
hardirq-read-unsafe locks: 312
softirq-read-safe locks: 12
softirq-read-unsafe locks: 307
irq-read-safe locks: 12
irq-read-unsafe locks: 312
uncategorized locks: 352
unused locks: 0
max locking depth: 30
max bfs queue depth: 379
max lock class index: 2073
debug_locks: 0
zapped classes: 6
zapped lock chains: 163
large chain blocks: 0
And, the average lock chain depth could be calculated as:
dependency chain hlocks used (327679) / dependency chains (51354) ~= 6.38
Seems like we should also consider bumping 'AVG_LOCKDEP_CHAIN_DEPTH' to
something like 7 or higher.
> CONFIG_LOCKDEP_CHAINS_BITS to at least 17, those we may still hit the
> "MAX_LOCKDEP_CHAIN_HLOCKS too low" if we run a variety of different
> workloads without reboot.
Agreed. We may still hit this issue, but tweaking these values can make
it less likely ;)
Thanks,
Lance
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2025-05-27 11:59 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2025-05-27 2:02 [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low Lance Yang
2025-05-27 4:48 ` Waiman Long
2025-05-27 5:33 ` Lance Yang
2025-05-27 5:53 ` Waiman Long
2025-05-27 11:59 ` Lance Yang
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).