Re: [PATCH] drm/edid: reduce update_display_info() stack usage

["Arnd Bergmann" <arnd@arndb.de>]

[-- Attachment #1: Type: text/plain, Size: 5198 bytes --]

On Thu, Oct 22, 2026, at 18:02, Alexander Potapenko wrote:
> On Thu, Oct 22, 2026 at 1:37 PM Jani Nikula <jani.nikula@intel.com> wrote:
>> On Mon, 19 Oct 2026, "Arnd Bergmann" <arnd@arndb.de> wrote:
>> > On Mon, Oct 19, 2026, at 15:28, Jani Nikula wrote:
>> >>
>> >> Is there really no way to tell the compiler to not do silly things in a
>> >> more generic way?
>> >
>> > The problem is really the sanitizers here, which turn off the
>> > optimizations that gcc relies on for its normal behavior and
>> > which cause additional register pressure for the inserted function
>> > calls.
>>
>> Cc: a bunch of KASAN folks.
>>
>> I think it's really silly and ugly to have to sprinkle
>> noinline_for_stack all over the place in pretty normal code [1]. The
>> stack usage for each individual function is fairly small.
>
> Together with my LLM friend, I did some digging to see whether this
> can be handled on the compiler side instead. Summary of what we found
> (x86_64 defconfig + KASAN_STACK,
> GCC 15.2 and Clang 21, -fstack-usage on every object):
> 1. The immediate cause here is that GCC's inliner has no idea what the
>    frame will cost under KASAN. Its stack estimate for a callee only
>    sums the raw sizes of address-taken locals, so it never includes
>    the ASan redzones and never sees the register spills that
>    instrumentation causes. For all nine parsers in drm_parse_cea_ext()
>    the estimate is literally 0 bytes, which short-circuits the
>    -fconserve-stack limits, and since each parser has a single caller,
>    -finline-functions-called-once inlines them regardless of size.
>
> 2. A generic knob therefore exists: passing
>    -fno-inline-functions-called-once under CONFIG_KASAN_STACK with GCC
>    brings update_display_info() from 704 to 344 bytes here without
>    touching the source (drm_parse_cea_ext stays a separate 368-byte
>    frame). Kernel-wide on that config it removes 22 of the 103 frames
>    above 1024 bytes and introduces 6 new ones, for +1.2% text.

Thanks for taking a look! This bit certainly makes sense, and I
could try to see what effect -fno-inline-functions-called-once has
overall when building a lot of randconfigs with KASAN. My guess
is that it would introduce some other cases that are currently
not causing warnings, but there is a good chance that it will be
an overall win.

> 3. The GCC estimate itself is also fixable (make account_stack_vars()
>    add the redzones it is going to allocate anyway, ~30 lines in
>    cfgexpand.cc). That reduces total KASAN stack usage by ~7% for
>    +0.35% text and fixes this particular case on its own (704 -> 368),
>    so it is probably worth upstreaming. But it is a correctness fix, not a
>    cure: it doesn't change the number of frames above 1024/2048 at all.

That certainly sounds useful. For my testing, I run with a heuristic
that adds sets of 256 bytes for certain features (KASAN, KASAN_STACK,
KMSAN, 64BIT, clang on ppc64, ...) to the baseline of 1024, in
order to catch as many kernel bugs from excessively large local
variables while not tripping up sanitizers too much. Any reduction
here would help reduce the warnings I see as well as the actual risk
of runtime stack overflow.

On a related note, I wonder if the size of the redzone could be
reduced for KASAN compared to userspace ASAN as the available
thread stack is much smaller. IIRC we already have rather different
calculations for the redzone between clang and gcc, so it
seems likely that we can reduce that a bit. 

> 4. The reason is that the big frames under KASAN are overwhelmingly
>    functions that already have 0.5-1.5KB of genuine locals without
>    KASAN (97 of the 103 above 1024 bytes); KASAN then multiplies them
>    by 1.5x (median) to 2.3x (p90) through redzones and spills. No
>    inlining heuristic can undo that, and this is inherent in how the
>    stack instrumentation works. So for KASAN_STACK builds we think
>    FRAME_WARN simply has to be higher than for regular builds. For
>    what it's worth, Clang does worse on the same config
>    (149 frames above 1024 vs. 103 for GCC, 1176 bytes for
>    update_display_info), which is why KASAN_STACK is already off by
>    default there.
>
> Arnd, one thing I could not do is reproduce the 1888 bytes: with
> linux-next's drm_edid.c the worst we get is 704 on x86_64, 752 on
> arm64 and 1264 on arm64 with PROFILE_ALL_BRANCHES. Could you share
> the .config and GCC version?

The reproducer I have is for s390, I have attached the .config here.
My guess is that I could find additional reproducers but I applied
my patch locally after the first hit, which stopped me from running
into others, but there is a chance that this is just extremely
rare.

If you are interested, I can also dig out other configurations
that still have frame size warnings upstream, and configs that
trigger them. My randconfig tree still has a few dozen workaround
that never got merged. The nasty ones tend to be those that
run into spilled registers when a santizer adds not just additional
redzones and functions calls but also register pressure.

     Arnd

[-- Attachment #2: 0x987E7BA6-config.gz --]
[-- Type: application/gzip, Size: 46821 bytes --]