lockdep: upper limit LOCKDEP_CHAINS_BITS

[PATCH v2] lockdep: upper limit LOCKDEP_CHAINS_BITS

Posted by Carlos Llamas 1 month, 2 weeks ago

From: "J. R. Okajima" <hooanon05g@gmail.com>

CONFIG_LOCKDEP_CHAINS_BITS value decides the size of chain_hlocks[] in
kernel/locking/lockdep.c, and it is checked by add_chain_cache() with
    BUILD_BUG_ON((1UL << 24) <= ARRAY_SIZE(chain_hlocks));
This patch is just to silence BUILD_BUG_ON().

See-also: https://lore.kernel.org/all/30795.1620913191@jrobl/
Cc: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Cc: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: J. R. Okajima <hooanon05g@gmail.com>
Acked-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
[cmllamas: fix minor checkpatch issues in commit log]
Signed-off-by: Carlos Llamas <cmllamas@google.com>
---
 lib/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index a30c03a66172..04668248225c 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1515,7 +1515,7 @@ config LOCKDEP_BITS
 config LOCKDEP_CHAINS_BITS
 	int "Bitsize for MAX_LOCKDEP_CHAINS"
 	depends on LOCKDEP && !LOCKDEP_SMALL
-	range 10 30
+	range 10 21
 	default 16
 	help
 	  Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message.
-- 
2.45.2.1089.g2a221341d9-goog

Re: [PATCH v2] lockdep: upper limit LOCKDEP_CHAINS_BITS

Posted by Andrew Morton 1 month, 1 week ago

On Tue, 23 Jul 2024 16:40:17 +0000 Carlos Llamas <cmllamas@google.com> wrote:

> From: "J. R. Okajima" <hooanon05g@gmail.com>
> 
> CONFIG_LOCKDEP_CHAINS_BITS value decides the size of chain_hlocks[] in
> kernel/locking/lockdep.c, and it is checked by add_chain_cache() with
>     BUILD_BUG_ON((1UL << 24) <= ARRAY_SIZE(chain_hlocks));
> This patch is just to silence BUILD_BUG_ON().
> 
> ...
>
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1515,7 +1515,7 @@ config LOCKDEP_BITS
>  config LOCKDEP_CHAINS_BITS
>  	int "Bitsize for MAX_LOCKDEP_CHAINS"
>  	depends on LOCKDEP && !LOCKDEP_SMALL
> -	range 10 30
> +	range 10 21
>  	default 16
>  	help
>  	  Try increasing this value if you hit "BUG: MAX_LOCKDEP_CHAINS too low!" message.

checking your homework...

With LOCKDEP_CHAINS_BITS == 21:

	#define MAX_LOCKDEP_CHAINS_BITS CONFIG_LOCKDEP_CHAINS_BITS

		gives MAX_LOCKDEP_CHAINS_BITS == 21

	#define MAX_LOCKDEP_CHAINS      (1UL << MAX_LOCKDEP_CHAINS_BITS)

		gives MAX_LOCKDEP_CHAINS == (1UL << 21)

	#define MAX_LOCKDEP_CHAIN_HLOCKS (MAX_LOCKDEP_CHAINS*5)

		gives MAX_LOCKDEP_CHAIN_HLOCKS = 5 * (1UL << 21)

	static u16 chain_hlocks[MAX_LOCKDEP_CHAIN_HLOCKS];

		gives ARRAY_SIZE(chain_hlocks) == 5 * (1UL << 21)

so

	BUILD_BUG_ON((1UL << 24) <= ARRAY_SIZE(chain_hlocks));
	ie, BUILD_BUG_ON((1UL << 24) <= 5 * (1UL << 21));

is OK, whereas

	BUILD_BUG_ON((1UL << 24) <= 5 * (1UL << 22));

will bug out.  So LGTM, I'll add it to mm.git.


btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd.  What's a
bitsize?  Maybe "bit shift count for..." or such.

Re: [PATCH v2] lockdep: upper limit LOCKDEP_CHAINS_BITS

Posted by Carlos Llamas 1 month ago

On Wed, Jul 31, 2024 at 04:48:23PM -0700, Andrew Morton wrote:
> btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd.  What's a
> bitsize?  Maybe "bit shift count for..." or such.

Yeah, maybe a _SHIFT suffix would have been better fit for these configs
instead of _BITS. Similar to PAGE_SHIFT or NODES_SHIFT. Anyways, I can
send a patch to improve the help text. How about something like:
   "Size for ... (as a power of 2)"

I'll also send a separate patch to fix the rest of the upper limits. Any
of the (1 << 30) shifts allocates static arrays that blow past the .bss
segment. Just as originally reporeted by J. R. Okajima.

--
Carlos Llamas

Re: [PATCH v2] lockdep: upper limit LOCKDEP_CHAINS_BITS

Posted by Carlos Llamas 1 month ago

On Mon, Aug 05, 2024 at 07:58:07PM +0000, Carlos Llamas wrote:
> On Wed, Jul 31, 2024 at 04:48:23PM -0700, Andrew Morton wrote:
> > btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd.  What's a
> > bitsize?  Maybe "bit shift count for..." or such.
> 
> Yeah, maybe a _SHIFT suffix would have been better fit for these configs
> instead of _BITS. Similar to PAGE_SHIFT or NODES_SHIFT. Anyways, I can
> send a patch to improve the help text. How about something like:
>    "Size for ... (as a power of 2)"
> 
> I'll also send a separate patch to fix the rest of the upper limits. Any
> of the (1 << 30) shifts allocates static arrays that blow past the .bss
> segment. Just as originally reporeted by J. R. Okajima.

Ok, I've sent a patchset for these bits at:
https://lore.kernel.org/all/20240806010128.402852-1-cmllamas@google.com/

Thanks,
Carlos Llamas

Re: [PATCH v2] lockdep: upper limit LOCKDEP_CHAINS_BITS

Posted by Carlos Llamas 1 month, 1 week ago

On Wed, Jul 31, 2024 at 04:48:23PM -0700, Andrew Morton wrote:
[...]
> so
> 
> 	BUILD_BUG_ON((1UL << 24) <= ARRAY_SIZE(chain_hlocks));
> 	ie, BUILD_BUG_ON((1UL << 24) <= 5 * (1UL << 21));
> 
> is OK, whereas
> 
> 	BUILD_BUG_ON((1UL << 24) <= 5 * (1UL << 22));
> 
> will bug out.  So LGTM, I'll add it to mm.git.
>

Right. I ran into the BUILD_BUG_ON() while trying to max out
LOCKDEP_CHAINS_BITS. I initially suspected the assert was incorrect as
the static array is being indexed as chain_hlocks[base + depth], which
according to the bitfileds in 'struct lock_chain' should likely be a 30
bit shift instead:

	unsigned int    irq_contex :  2,
			depth      :  6,
			base       : 24;

In practice though, using 1UL << 30 will blow up the bss section. This
is also true for the _any_ of the CONFIG_LOCKDEP_*_BITS. As they are all
shifts to determine the size of static arrays.

I simply dug up this patch from J.R. which avoids the BUILD_BUG_ON(),
but perhaps someone should limit the rest of the configs? In practice,
nobody should be using these 30 bit shifts.

> btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd.  What's a
> bitsize?  Maybe "bit shift count for..." or such.

Indeed that is odd. I'm also not sure what to make of the "*5" magic
number. I suppose it could be the typical lock depth? I could try to
clarify these points, if no one with more insight wants to do it.

--
Carlos Llamas

Re: [PATCH v2] lockdep: upper limit LOCKDEP_CHAINS_BITS

Posted by J. R. Okajima 1 month ago

Carlos Llamas:
> I simply dug up this patch from J.R. which avoids the BUILD_BUG_ON(),
> but perhaps someone should limit the rest of the configs? In practice,
> nobody should be using these 30 bit shifts.

I posted the patch in 2021. It was against the commit in v5.13-rc1,
        5dc33592e9553 2021-04-05 lockdep: Allow tuning tracing capacity constants.
It is a little surprise for me that you could pick up such old post.

As I wrote in the old post
	https://lore.kernel.org/all/30795.1620913191@jrobl/
	I don't know what this 'multiply by 5' means and why
	ARRAY_SIZE(chain_hlocks) is limited to (1UL << 24)
And the post is just to silence BUILD_BUG_ON().
There are a few more "range 10 30" in lib/Kconfig.debug.


> > btw, the help text "Bitsize for MAX_LOCKDEP_CHAINS" is odd.  What's a
> > bitsize?  Maybe "bit shift count for..." or such.
>
> Indeed that is odd. I'm also not sure what to make of the "*5" magic
> number. I suppose it could be the typical lock depth? I could try to
> clarify these points, if no one with more insight wants to do it.

Also the original text comes from the commit in v5.13-rc1.


J. R. Okajima