Re: [PATCH v8 24/27] FOR-CI: bump MAX_STACK_TRACE_ENTRIES

[sashiko-bot@kernel.org]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [High] Unacceptable minimum memory footprint for lockdep and global CI hack
- [Medium] Commit message and code mismatch: missing 'reset lockdep' logic
- [Low] Stale Kconfig help text regarding KASAN default
--

commit 6acd80559fe23be49729943270ef9f9a1fa2feeb
Author: Maarten Lankhorst <dev@lankhorst.se>

FOR-CI: bump MAX_STACK_TRACE_ENTRIES

This patch modifies the LOCKDEP_STACK_TRACE_BITS Kconfig limits to address a
bug in CI where MAX_STACK_TRACE_ENTRIES is set too low. It restricts the
allowed range for this value and sets a new default of 22.

> FOR-CI: bump MAX_STACK_TRACE_ENTRIES
>
> We're hitting a bug in CI where MAX_STACK_TRACE_ENTRIES is set too low.
> My guess is the repeated loading/unloading is creating multiples of the
> same entries. As a hack just reset lockdep. This might only be necessary
> for CI + PREEMPT_RT.

[Severity: Medium]
Is the commit message outdated, or is the logic to reset lockdep missing?

The message mentions resetting lockdep as a hack, but the patch only modifies
the LOCKDEP_STACK_TRACE_BITS limits in Kconfig and includes no code changes
to perform any lockdep reset.

> diff --git a/lib/Kconfig.debug b/lib/Kconfig.debug
> index e2f976c3301b6..1e670aa6a0812 100644
> --- a/lib/Kconfig.debug
> +++ b/lib/Kconfig.debug
> @@ -1617,9 +1617,8 @@ config LOCKDEP_CHAINS_BITS
>  config LOCKDEP_STACK_TRACE_BITS
>  	int "Size for MAX_STACK_TRACE_ENTRIES (as Nth power of 2)"
>  	depends on LOCKDEP && !LOCKDEP_SMALL
> -	range 10 26
> -	default 21 if KASAN
> -	default 19
> +	range 22 26
> +	default 22

[Severity: High]
Does this force a massive minimum memory footprint on all systems?

Bumping the range to a minimum of 22 forces 2^22 (4,194,304) entries globally
for all builds with lockdep enabled. On 64-bit systems, this mandates a
minimum allocation of roughly 33.5 MB of kernel memory. 

Is it possible to avoid forcing this large footprint on memory-constrained
embedded systems just for a CI workaround?

>  	help
>  	  Try increasing this value if you hit "BUG: MAX_STACK_TRACE_ENTRIES too low!" message.

[Severity: Low]
Does the help text below this line need to be updated?

The KASAN conditional default was removed, but the extended help text still
reads "The higher default when KASAN is enabled costs ~12MB extra..." which
is now stale and contradicts the new configuration limits.

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260615201846.307297-1-dev@lankhorst.se?part=24