mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Lance Yang <lance.yang@linux.dev>
To: Waiman Long <llong@redhat.com>, peterz@infradead.org
Cc: mingo@redhat.com, will@kernel.org, boqun.feng@gmail.com,
	linux-kernel@vger.kernel.org, Lance Yang <ioworker0@gmail.com>,
	Zi Li <zi.li@linux.dev>
Subject: Re: [WARN] LOCKDEP: MAX_LOCKDEP_CHAIN_HLOCKS too low
Date: Tue, 27 May 2025 13:33:57 +0800	[thread overview]
Message-ID: <055a9abd-8137-4382-9830-551961cbcda2@linux.dev> (raw)
In-Reply-To: <c0fb67e3-ebe0-45ec-9f61-a8cd5949cc42@redhat.com>

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
> 


  reply	other threads:[~2025-05-27  5:34 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
2025-05-27  5:33   ` Lance Yang [this message]
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=055a9abd-8137-4382-9830-551961cbcda2@linux.dev \
    --to=lance.yang@linux.dev \
    --cc=boqun.feng@gmail.com \
    --cc=ioworker0@gmail.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=llong@redhat.com \
    --cc=mingo@redhat.com \
    --cc=peterz@infradead.org \
    --cc=will@kernel.org \
    --cc=zi.li@linux.dev \
    /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®