linux-kernel - Re: riscv gcc-13 allyesconfig error the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]

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: <692e313d-ea31-45c0-8c66-36b25c9d955d@app.fastmail.com>
Date: Fri, 23 May 2025 20:01:33 +0200
From: "Arnd Bergmann" <arnd@...db.de>
To: "Kent Overstreet" <kent.overstreet@...ux.dev>
Cc: "Naresh Kamboju" <naresh.kamboju@...aro.org>,
 linux-bcache@...r.kernel.org, "open list" <linux-kernel@...r.kernel.org>,
 lkft-triage@...ts.linaro.org,
 "Linux Regressions" <regressions@...ts.linux.dev>,
 "Dan Carpenter" <dan.carpenter@...aro.org>,
 "Anders Roxell" <anders.roxell@...aro.org>
Subject: Re: riscv gcc-13 allyesconfig error the frame size of 2064 bytes is larger
 than 2048 bytes [-Werror=frame-larger-than=]

On Fri, May 23, 2025, at 19:11, Kent Overstreet wrote:
> On Fri, May 23, 2025 at 05:17:15PM +0200, Arnd Bergmann wrote:
>> 
>> - KASAN_STACK adds extra redzones for each variable
>> - KASAN_STACK further prevents stack slots from getting
>>   reused inside one function, in order to better pinpoint
>>   which instance caused problems like out-of-scope access
>> - passing structures by value causes them to be put on
>>   the stack on some architectures, even when the structure
>>   size is only one or two registers
>
> We mainly do this with bkey_s_c, which is just two words: on x86_64,
> that gets passed in registers. Is riscv different?

Not sure, I think it's mostly older ABIs that are limited,
either not passing structures in registers at all, or only
possibly one but not two of them.

>> - sanitizers turn off optimizations that lead to better
>>   stack usage
>> - in some cases, the missed optimization ends up causing
>>   local variables to get spilled to the stack many times
>>   because of a combination of all the above.
>
> Yeesh.
>
> I suspect we should be running with a larger stack when the sanitizers
> are running, and perhaps tweak the warnings accordingly. I did a bunch
> of stack usage work after I found a kmsan build was blowing out the
> stack, but then running with max stack usage tracing enabled showed it
> to be a largely non issue on non-sanitizer builds, IIRC.

Enabling KASAN does double the available stack space. However, I don't
think we should use that as an excuse to raise the per-function
warning limit, because

 - the majority of all function stacks do not grow that much when
   sanitizers are enabled
 - allmodconfig enables KASAN and should still catch mistakes
   where a driver accidentally puts a large structure on the stack
 - 2KB on 64-bit targes is a really large limit. At some point
   in the past I had a series that lowered the limit to 1536 byte
   for 64-bit targets, but I never managed to get all the changes
   merged.
  

     Arnd