From: Waiman Long <llong@redhat.com>
To: Lance Yang <ioworker0@gmail.com>, peterz@infradead.org
Cc: mingo@redhat.com, will@kernel.org, boqun.feng@gmail.com,
linux-kernel@vger.kernel.org
Subject: Re: [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low
Date: Tue, 27 May 2025 00:48:21 -0400 [thread overview]
Message-ID: <c0fb67e3-ebe0-45ec-9f61-a8cd5949cc42@redhat.com> (raw)
In-Reply-To: <20250527020252.43684-1-lance.yang@linux.dev>
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
next prev parent reply other threads:[~2025-05-27 4:48 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-05-27 2:02 Lance Yang
2025-05-27 4:48 ` Waiman Long [this message]
2025-05-27 5:33 ` Lance Yang
2025-05-27 5:53 ` Waiman Long
2025-05-27 11:59 ` Lance Yang
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=c0fb67e3-ebe0-45ec-9f61-a8cd5949cc42@redhat.com \
--to=llong@redhat.com \
--cc=boqun.feng@gmail.com \
--cc=ioworker0@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=peterz@infradead.org \
--cc=will@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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®