[PATCH] mm/damon/core: reduce kernel stack usage

[PATCH] mm/damon/core: reduce kernel stack usage

[Arnd Bergmann]

From: Arnd Bergmann <arnd@arndb.de>

The main thread function has recently grown to the point of
exceeding stack frame size warning limits in some configurations.
This is what I hit on s390 with clang and CONFIG_KASAN:

mm/damon/core.c:3440:31: error: stack frame size (1352) exceeds limit (1280) in 'kdamond_fn' [-Werror,-Wframe-larger-than]
 3440 | static int kdamond_fn(struct damon_ctx *ctx)

The largest stack usage here is inside of the kdamond_tune_intervals(),
so by marking that one as noinline_for_stack, the functions individually
stay below the warning limit, though kdamond_fn() itself still uses
hundreds of kilobytes for some reason.

Signed-off-by: Arnd Bergmann <arnd@arndb.de>
---
 mm/damon/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/mm/damon/core.c b/mm/damon/core.c
index 265d51ade25b..69f38c48ac08 100644
--- a/mm/damon/core.c
+++ b/mm/damon/core.c
@@ -2002,7 +2002,7 @@ static unsigned long damon_get_intervals_adaptation_bp(struct damon_ctx *c)
 	return adaptation_bp;
 }
 
-static void kdamond_tune_intervals(struct damon_ctx *c)
+static noinline_for_stack void kdamond_tune_intervals(struct damon_ctx *c)
 {
 	unsigned long adaptation_bp;
 	struct damon_attrs new_attrs;
-- 
2.39.5

Re: [PATCH] mm/damon/core: reduce kernel stack usage

[SeongJae Park]

On Thu, 11 Jun 2026 14:56:57 +0200 Arnd Bergmann <arnd@kernel.org> wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> 
> The main thread function has recently grown to the point of
> exceeding stack frame size warning limits in some configurations.
> This is what I hit on s390 with clang and CONFIG_KASAN:
> 
> mm/damon/core.c:3440:31: error: stack frame size (1352) exceeds limit (1280) in 'kdamond_fn' [-Werror,-Wframe-larger-than]
>  3440 | static int kdamond_fn(struct damon_ctx *ctx)
> 
> The largest stack usage here is inside of the kdamond_tune_intervals(),
> so by marking that one as noinline_for_stack, the functions individually
> stay below the warning limit, though kdamond_fn() itself still uses
> hundreds of kilobytes for some reason.

Thank you for this fix, Arnd!  I will also take a look in kdamond_fn() to see
if there are more things to reduce.

> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>

Reviewed-by: SeongJae Park <sj@kernel.org>

Should we add Fixes: and Cc: stable@ too?  This function was introduced by
commit f04b0fedbe71 ("mm/damon/core: implement intervals auto-tuning") which
was merged into 6.15.


Thanks,
SJ

[...]

Re: [PATCH] mm/damon/core: reduce kernel stack usage

[Andrew Morton]

On Thu, 11 Jun 2026 06:56:07 -0700 SeongJae Park <sj@kernel.org> wrote:

> On Thu, 11 Jun 2026 14:56:57 +0200 Arnd Bergmann <arnd@kernel.org> wrote:
> 
> > From: Arnd Bergmann <arnd@arndb.de>
> > 
> > The main thread function has recently grown to the point of
> > exceeding stack frame size warning limits in some configurations.
> > This is what I hit on s390 with clang and CONFIG_KASAN:
> > 
> > mm/damon/core.c:3440:31: error: stack frame size (1352) exceeds limit (1280) in 'kdamond_fn' [-Werror,-Wframe-larger-than]
> >  3440 | static int kdamond_fn(struct damon_ctx *ctx)

Well cheers to s390 for using a nice tight stack limit.

> > The largest stack usage here is inside of the kdamond_tune_intervals(),
> > so by marking that one as noinline_for_stack, the functions individually
> > stay below the warning limit, though kdamond_fn() itself still uses
> > hundreds of kilobytes for some reason.

Wait what wut.  This cannot mean that kdamond_fn() uses x00,000 bytes of
stack, so what does it mean?

> Thank you for this fix, Arnd!  I will also take a look in kdamond_fn() to see
> if there are more things to reduce.
> 
> > 
> > Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> 
> Reviewed-by: SeongJae Park <sj@kernel.org>
> 
> Should we add Fixes: and Cc: stable@ too?  This function was introduced by
> commit f04b0fedbe71 ("mm/damon/core: implement intervals auto-tuning") which
> was merged into 6.15.

I don't think so - kernel is full of these offenders and it will be a
long and painstaking process to weed them out.

Re: [PATCH] mm/damon/core: reduce kernel stack usage

[SJ Park]

On Sat, 27 Jun 2026 22:34:05 -0700 Andrew Morton <akpm@linux-foundation.org> wrote:

> On Thu, 11 Jun 2026 06:56:07 -0700 SeongJae Park <sj@kernel.org> wrote:
> 
> > On Thu, 11 Jun 2026 14:56:57 +0200 Arnd Bergmann <arnd@kernel.org> wrote:
[...]
> > Should we add Fixes: and Cc: stable@ too?  This function was introduced by
> > commit f04b0fedbe71 ("mm/damon/core: implement intervals auto-tuning") which
> > was merged into 6.15.
> 
> I don't think so - kernel is full of these offenders and it will be a
> long and painstaking process to weed them out.

Thank you for input, Andrew.  I agree.


Thanks,
SJ

Sent using hkml (https://github.com/sjp38/hackermail)

Re: [PATCH] mm/damon/core: reduce kernel stack usage

[Arnd Bergmann]

On Sun, Jun 28, 2026, at 07:34, Andrew Morton wrote:
> On Thu, 11 Jun 2026 06:56:07 -0700 SeongJae Park <sj@kernel.org> wrote:
>
>> On Thu, 11 Jun 2026 14:56:57 +0200 Arnd Bergmann <arnd@kernel.org> wrote:
>> 
>> > From: Arnd Bergmann <arnd@arndb.de>
>> > 
>> > The main thread function has recently grown to the point of
>> > exceeding stack frame size warning limits in some configurations.
>> > This is what I hit on s390 with clang and CONFIG_KASAN:
>> > 
>> > mm/damon/core.c:3440:31: error: stack frame size (1352) exceeds limit (1280) in 'kdamond_fn' [-Werror,-Wframe-larger-than]
>> >  3440 | static int kdamond_fn(struct damon_ctx *ctx)
>
> Well cheers to s390 for using a nice tight stack limit.

To clarify, this is a stack limit that I use for my randconfig build
across architectures, the default limit on allmodconfig is still 2048
bytes, and s390 generally needs a little more stack than most
other architectures.

>
>> > The largest stack usage here is inside of the kdamond_tune_intervals(),
>> > so by marking that one as noinline_for_stack, the functions individually
>> > stay below the warning limit, though kdamond_fn() itself still uses
>> > hundreds of kilobytes for some reason.
>
> Wait what wut.  This cannot mean that kdamond_fn() uses x00,000 bytes of
> stack, so what does it mean?

bytes, not kilobytes, sorry for the typo!

>> Should we add Fixes: and Cc: stable@ too?  This function was introduced by
>> commit f04b0fedbe71 ("mm/damon/core: implement intervals auto-tuning") which
>> was merged into 6.15.
>
> I don't think so - kernel is full of these offenders and it will be a
> long and painstaking process to weed them out.

I'm mainly pushing back on regressions when they happen. In my test
tree, I have a patch that adds a few bytes for Kconfig options that
cause particularly large stack frames (CONFIG_KASAN_STACK,
CONFIG_KASAN, CONFIG_64BIT, CONFIG_UBSAN_ALIGNMENT) but otherwise
use the traditional 1024 byte limit, and I send patches when I
run into any function that uses more. I have never managed to
get my backlog small enough to actually send the patch that
changes the default limits.

Right now I have

5bd54760fba1 [SUBMITTED 20260622] drm/amd/display: kunit: move dc_link objects off stack
262678481abf [SUBMITTED 20260618] usb: ucsi: huawei_gaokun: move typec_altmode off stack
2cb955c0b224 [SUBMITTED 20260618] media: v4l2-tpg: reduce stack usage for kasan builds
dfdc80171d8d [SUBMITTED 20260612] mlx5: avoid frame overflow warning
e252ac86b090 [SUBMITTED 20260611] drm/amd/display: avoid large stack allocation in 
97582da9074d [SUBMITTED 20260611] [wireless-next] wifi: mac80211: allocate backup ieee80211_nan_sched_cfg off stack
2f707af98b86 [SUBMITTED 20260611] mm/damon/core: reduce kernel stack usage
9fe35d5f1de6 [SUBMITTED 20260526] zstd: reducing inlining for KASAN_STACK
82daa7698bbe [SUBMITTED 20260520] fat: avoid stack overflow warning
dd7d4b16c1d0 [SUBMITTED 20260515] bpf: test_run: reduce kernel stack usage
75b3f86afb91 [SUBMITTED 20260515] irqchip/ast2700-intc: reduce stack usage in kunit tests
c5d5e99dfe31 [SUBMITTED 20250620] perf/arm-cmn: reduce stack usage in arm_cmn_probe()
80587b5964a1 [SUBMITTED 20250620] coredump: reduce stack usage in vfs_coredump()
89e40670333d [SUBMITTED 20250620] lib/tests: split randstruct initializer tests
723381a3739f [SUBMITTED 20250620] binfmt_elf: reduce stackusage in kunit test
9f7e36aa0b81 [SUBMITTED 20250620] [RFC] net/mlx5: don't build with CONFIG_CPUMASK_OFFSTACK
7a5ea46be400 [SUBMITTED 20250620] coresight: fix building with CONFIG_CPUMASK_OFFSTACK
40398f198b2b [SUBMITTED 20250610] drm/radeon: reduce stack frame size for radeon_cs_ioctl
b52879e6b419 [SUBMITTED 20250221] ntb: reduce stack usage in idt_scan_mws

and some patches that I have never sent so far. This is clearly an
uphill battle, but kernel stack overflows are a real and build testing
with a reasonably small limit is only one line of defense against these.

     Arnd

Re: [PATCH] mm/damon/core: reduce kernel stack usage

[Andrew Morton]

On Tue, 30 Jun 2026 15:29:03 +0200 "Arnd Bergmann" <arnd@arndb.de> wrote:

> This is clearly an
> uphill battle, but kernel stack overflows are a real and build testing
> with a reasonably small limit is only one line of defense against these.

It's a worthy battle.

Reducing the default CONFIG_FRAME_WARN on various architectures will
help.  It's kinda trollish, but we should clamp down on this stuff and
having Arnd plugging away on his own isn't a good way!

Re: [PATCH] mm/damon/core: reduce kernel stack usage

[David Laight]

On Thu, 11 Jun 2026 14:56:57 +0200
Arnd Bergmann <arnd@kernel.org> wrote:

> From: Arnd Bergmann <arnd@arndb.de>
> 
> The main thread function has recently grown to the point of
> exceeding stack frame size warning limits in some configurations.
> This is what I hit on s390 with clang and CONFIG_KASAN:
> 
> mm/damon/core.c:3440:31: error: stack frame size (1352) exceeds limit (1280) in 'kdamond_fn' [-Werror,-Wframe-larger-than]
>  3440 | static int kdamond_fn(struct damon_ctx *ctx)
> 
> The largest stack usage here is inside of the kdamond_tune_intervals(),
> so by marking that one as noinline_for_stack, the functions individually
> stay below the warning limit, though kdamond_fn() itself still uses
> hundreds of kilobytes for some reason.

Does that actually reduce the stack use if the functions are called?
Or just stop the compiler bleating and running the code is still likely
to overflow the stack.

I keep thinking it should be possible to get (say) objtool to output
the stack offsets of every call.
With (I think it is) fine-ibt the hashes can be used so separate all the
indirect calls (although you might need a 'salt' to separate the different
'void (*)(void *)' functions - that probably ought to be done anyway).
Then it is a SMOP to generate a maximal stack depth for each function and
to detect the recursive loops.

I did that many many years ago for an embedded system (no indirect calls),
the outcome was that we didn't have enough memory to allow for the worst
case stack use!
The deep places were all (the equivalent of) printk() in pretty
impossible error paths.

-- David


> 
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> ---
>  mm/damon/core.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/mm/damon/core.c b/mm/damon/core.c
> index 265d51ade25b..69f38c48ac08 100644
> --- a/mm/damon/core.c
> +++ b/mm/damon/core.c
> @@ -2002,7 +2002,7 @@ static unsigned long damon_get_intervals_adaptation_bp(struct damon_ctx *c)
>  	return adaptation_bp;
>  }
>  
> -static void kdamond_tune_intervals(struct damon_ctx *c)
> +static noinline_for_stack void kdamond_tune_intervals(struct damon_ctx *c)
>  {
>  	unsigned long adaptation_bp;
>  	struct damon_attrs new_attrs;

Re: [PATCH] mm/damon/core: reduce kernel stack usage

[Arnd Bergmann]

On Thu, Jun 11, 2026, at 20:50, David Laight wrote:
> On Thu, 11 Jun 2026 14:56:57 +0200
> Arnd Bergmann <arnd@kernel.org> wrote:
>
>> From: Arnd Bergmann <arnd@arndb.de>
>> 
>> The main thread function has recently grown to the point of
>> exceeding stack frame size warning limits in some configurations.
>> This is what I hit on s390 with clang and CONFIG_KASAN:
>> 
>> mm/damon/core.c:3440:31: error: stack frame size (1352) exceeds limit (1280) in 'kdamond_fn' [-Werror,-Wframe-larger-than]
>>  3440 | static int kdamond_fn(struct damon_ctx *ctx)
>> 
>> The largest stack usage here is inside of the kdamond_tune_intervals(),
>> so by marking that one as noinline_for_stack, the functions individually
>> stay below the warning limit, though kdamond_fn() itself still uses
>> hundreds of kilobytes for some reason.
>
> Does that actually reduce the stack use if the functions are called?
> Or just stop the compiler bleating and running the code is still likely
> to overflow the stack.

The one code path that was identified by the compiler does not
improve, as the sum of the caller and the callee is still the
same. As far as I can tell, the stack usage in gcc is similar
in this code path, but it doesn't warn because the normal
inliner does not combine these two.

It does help in other leaf functions called by kdamond_fn() that
now don't have the kdamond_tune_intervals() variables on the
stack on top of their own ones, so in any other extern function
called indirectly by kdamond_fn, more stack space is available.

> I did that many many years ago for an embedded system (no indirect calls),
> the outcome was that we didn't have enough memory to allow for the worst
> case stack use!
> The deep places were all (the equivalent of) printk() in pretty
> impossible error paths.

Yes, that is a well known problem: it is very easy to construct
call chains that are possible in the kernel that go way beyond
any sensible size limit. Importantly, any GFP_KERNEL allocation
can end up in the file system reclaim path.

The -Wframe-larger-than= warnings are just one way to make
this less likely to happen.

     Arnd