[PATCH] lockdep: Fix upper limit for LOCKDEP_BITS configs

[PATCH] lockdep: Fix upper limit for LOCKDEP_BITS configs

[Xiaomeng Zhang]

The upper limit that was initially setup for LOCKDEP_BITS configs
is too high (24 bit shift), which causes the kernel image size to exceed
KERNEL_IMAGE_SIZE (1024MB) limit. When LOCKDEP_BITS is set to 24,
the kernel image size grows to 1562.19MB.

Adjust LOCKDEP_BITS to 22, which results in a kernel image size of
888.19MB, keeping it under the KERNEL_IMAGE_SIZE limit while still
maintaining adequate debug information capacity.

This change prevents the linker error:
  ld: kernel image bigger than KERNEL_IMAGE_SIZE

Fixes: e638072e6172 ("lockdep: Fix upper limit for LOCKDEP_*_BITS configs")
Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13@huawei.com>
---
 lib/Kconfig.debug | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
index 35796c290ca3..6faba965a349 100644
--- a/lib/Kconfig.debug
+++ b/lib/Kconfig.debug
@@ -1504,7 +1504,7 @@ config LOCKDEP_SMALL
 config LOCKDEP_BITS
 	int "Size for MAX_LOCKDEP_ENTRIES (as Nth power of 2)"
 	depends on LOCKDEP && !LOCKDEP_SMALL
-	range 10 24
+	range 10 22
 	default 15
 	help
 	  Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message.
-- 
2.34.1

Re: [PATCH] lockdep: Fix upper limit for LOCKDEP_BITS configs

[Waiman Long]

On 3/14/25 2:47 AM, Xiaomeng Zhang wrote:
> The upper limit that was initially setup for LOCKDEP_BITS configs
> is too high (24 bit shift), which causes the kernel image size to exceed
> KERNEL_IMAGE_SIZE (1024MB) limit. When LOCKDEP_BITS is set to 24,
> the kernel image size grows to 1562.19MB.
>
> Adjust LOCKDEP_BITS to 22, which results in a kernel image size of
> 888.19MB, keeping it under the KERNEL_IMAGE_SIZE limit while still
> maintaining adequate debug information capacity.
>
> This change prevents the linker error:
>    ld: kernel image bigger than KERNEL_IMAGE_SIZE
>
> Fixes: e638072e6172 ("lockdep: Fix upper limit for LOCKDEP_*_BITS configs")
> Signed-off-by: Xiaomeng Zhang <zhangxiaomeng13@huawei.com>
> ---
>   lib/Kconfig.debug | 2 +-
>   1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index 35796c290ca3..6faba965a349 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1504,7 +1504,7 @@ config LOCKDEP_SMALL
>   config LOCKDEP_BITS
>   	int "Size for MAX_LOCKDEP_ENTRIES (as Nth power of 2)"
>   	depends on LOCKDEP && !LOCKDEP_SMALL
> -	range 10 24
> +	range 10 22
>   	default 15
>   	help
>   	  Try increasing this value if you hit "BUG: MAX_LOCKDEP_ENTRIES too low!" message.

The current size of lock_list structure is 56 bytes. If we have 2^24 of 
them, they will occupy 896 Mbytes. That leaves about 100 Mbytes for the 
rest. Yes, we should reduce it further.

Acked-by: Waiman Long <longman@redhat.com>

Re: [PATCH] lockdep: Fix upper limit for LOCKDEP_BITS configs

[Carlos Llamas]

On Fri, Mar 14, 2025 at 06:47:29AM +0000, Xiaomeng Zhang wrote:
> The upper limit that was initially setup for LOCKDEP_BITS configs
> is too high (24 bit shift), which causes the kernel image size to exceed
> KERNEL_IMAGE_SIZE (1024MB) limit. When LOCKDEP_BITS is set to 24,
> the kernel image size grows to 1562.19MB.

This is not entirely accurate. Look at _how_ the new upper limits where
determined in commit e638072e6172. This should build just fine:

	$ make defconfig
	$ ./scripts/config -e PROVE_LOCKING --set-val LOCKDEP_BITS 24
	$ make -s olddefconfig all

Is it not the case for you? My guess is that you've also changed _other_
configs and combined with that you hit the limit. If not, can you please
provide the steps and commit you are using?

Thanks,
--
Carlos Llamas

回复: [PATCH] lockdep: Fix upper limit for LOCKDEP_BITS configs

[zhangxiaomeng (A)]

Thank you for the response. I should clarify that the issue occurs when modifying additional config values. Specifically, when LOCKDEP_BITS is set to 24 along with setting LOCKDEP_CHAINS_BITS and LOCKDEP_STACK_TRACE_BITS to their maximum upper limits, the build fails.

Here are the exact steps to reproduce:

Run make menuconfig
Enable CONFIG_PROVE_LOCKING
Set the following values:
LOCKDEP_CHAINS_BITS = 21
LOCKDEP_BITS = 24
LOCKDEP_STACK_TRACE_BITS = 26
Build kernel 6.6 with make -j122

-----邮件原件-----
发件人: Carlos Llamas <cmllamas@google.com> 
发送时间: 2025年3月15日 2:33
收件人: zhangxiaomeng (A) <zhangxiaomeng13@huawei.com>
抄送: Andrew Morton <akpm@linux-foundation.org>; linux-kernel@vger.kernel.org; Boqun Feng <boqun.feng@gmail.com>; J. R. Okajima <hooanon05g@gmail.com>; Peter Zijlstra <peterz@infradead.org>; Waiman Long <longman@redhat.com>; Ingo Molnar <mingo@redhat.com>; Will Deacon <will@kernel.org>
主题: Re: [PATCH] lockdep: Fix upper limit for LOCKDEP_BITS configs

On Fri, Mar 14, 2025 at 06:47:29AM +0000, Xiaomeng Zhang wrote:
> The upper limit that was initially setup for LOCKDEP_BITS configs is 
> too high (24 bit shift), which causes the kernel image size to exceed 
> KERNEL_IMAGE_SIZE (1024MB) limit. When LOCKDEP_BITS is set to 24, the 
> kernel image size grows to 1562.19MB.

This is not entirely accurate. Look at _how_ the new upper limits where determined in commit e638072e6172. This should build just fine:

	$ make defconfig
	$ ./scripts/config -e PROVE_LOCKING --set-val LOCKDEP_BITS 24
	$ make -s olddefconfig all

Is it not the case for you? My guess is that you've also changed _other_ configs and combined with that you hit the limit. If not, can you please provide the steps and commit you are using?

Thanks,
--
Carlos Llamas

Re: 回复: [PATCH] lockdep: Fix upper limit for LOCKDEP_BITS configs

[Carlos Llamas]

On Wed, Mar 19, 2025 at 09:48:11AM +0000, zhangxiaomeng (A) wrote:
> Thank you for the response. I should clarify that the issue occurs when modifying additional config values. Specifically, when LOCKDEP_BITS is set to 24 along with setting LOCKDEP_CHAINS_BITS and LOCKDEP_STACK_TRACE_BITS to their maximum upper limits, the build fails.

Right, that's what I figured. I don't know that bumping all these values
to their limit at once makes sense. I think allowing LOCKDEP_BITS to go
higher independently might still be useful so I don't see a reason to
change that.

--
Carlos Llamas