linux-kernel - Re: [PATCH v2] stackdepot: Make max number of pools build-time configurable

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <20250704133500.c21fc228600f70c51a16e04c@linux-foundation.org>
Date: Fri, 4 Jul 2025 13:35:00 -0700
From: Andrew Morton <akpm@...ux-foundation.org>
To: Matt Fleming <matt@...dmodwrite.com>
Cc: linux-kernel@...r.kernel.org, kernel-team@...udflare.com, Marco Elver
 <elver@...gle.com>, Alexander Potapenko <glider@...gle.com>, Andrey
 Konovalov <andreyknvl@...il.com>, Dmitry Vyukov <dvyukov@...gle.com>, Oscar
 Salvador <osalvador@...e.de>, Vlastimil Babka <vbabka@...e.cz>, Matt
 Fleming <mfleming@...udflare.com>
Subject: Re: [PATCH v2] stackdepot: Make max number of pools build-time
 configurable

On Fri,  4 Jul 2025 13:06:04 +0100 Matt Fleming <matt@...dmodwrite.com> wrote:

> From: Matt Fleming <mfleming@...udflare.com>
> 
> We're hitting the WARN in depot_init_pool() about reaching the stack
> depot limit because we have long stacks that don't dedup very well.
> 
> Introduce a new config to allow users to set the number of maximum stack
> depot pools at build time. Also, turn the silent capping into a
> build-time assert to provide more obvious feedback when users set this
> value too high.
> 
> ...
>
> --- a/lib/Kconfig
> +++ b/lib/Kconfig
> @@ -720,6 +720,12 @@ config STACKDEPOT_MAX_FRAMES
>  	default 64
>  	depends on STACKDEPOT
>  
> +config STACKDEPOT_MAX_POOLS
> +	int "Maximum number of stack depot pools to store stack traces" if EXPERT
> +	range 1024 131071
> +	default 8192
> +	depends on STACKDEPOT

Do we need a range?  If someone wants values outside the range they'll
just edit the Kconfig, shrug.

>  config REF_TRACKER
>  	bool
>  	depends on STACKTRACE_SUPPORT
> diff --git a/lib/stackdepot.c b/lib/stackdepot.c
> index 245d5b416699..1c25c40f31f9 100644
> --- a/lib/stackdepot.c
> +++ b/lib/stackdepot.c
> @@ -36,11 +36,11 @@
>  #include <linux/memblock.h>
>  #include <linux/kasan-enabled.h>
>  
> -#define DEPOT_POOLS_CAP 8192
> +#define DEPOT_MAX_POOLS CONFIG_STACKDEPOT_MAX_POOLS

A boot-time option would be much friendlier.  Can we dynamically
allocate stack_pools[]?

Or possibly even runtime, although perhaps not a good effort-to-utility
ratio.