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@xxxxxxxxxx> wrote:
>
>> On Thu, 11 Jun 2026 14:56:57 +0200 Arnd Bergmann <arnd@xxxxxxxxxx> wrote:
>> 
>> > From: Arnd Bergmann <arnd@xxxxxxxx>
>> > 
>> > 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