Linux bcache driver list
 help / color / mirror / Atom feed
From: "Arnd Bergmann" <arnd@arndb.de>
To: "Kent Overstreet" <kent.overstreet@linux.dev>
Cc: "Naresh Kamboju" <naresh.kamboju@linaro.org>,
	linux-bcache@vger.kernel.org,
	"open list" <linux-kernel@vger.kernel.org>,
	lkft-triage@lists.linaro.org,
	"Linux Regressions" <regressions@lists.linux.dev>,
	"Dan Carpenter" <dan.carpenter@linaro.org>,
	"Anders Roxell" <anders.roxell@linaro.org>
Subject: Re: riscv gcc-13 allyesconfig error the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
Date: Fri, 23 May 2025 17:17:15 +0200	[thread overview]
Message-ID: <566aefc9-7cad-4eb8-8eb0-8640d745efa2@app.fastmail.com> (raw)
In-Reply-To: <7tsvzu2mubrpclr75yezqj7ncuzebpsgqskbehhjy6gll73rez@5cj7griclubx>

On Fri, May 23, 2025, at 16:08, Kent Overstreet wrote:
> On Fri, May 23, 2025 at 03:49:54PM +0200, Arnd Bergmann wrote:
>> On Fri, May 23, 2025, at 15:19, Naresh Kamboju wrote:
>
>> I reproduced the problem locally and found this to go down to
>> 1440 bytes after I turn off KASAN_STACK. next-20250523 has
>> some changes that take the number down further to 1136 with
>> KASAN_STACK and or 1552 with KASAN_STACK.
>> 
>> I've turned bcachefs with kasan-stack on for my randconfig
>> builds again to see if there are any remaining corner cases.
>
> Thanks for the numbers - that does still seem high, I'll have to have a
> look with pahole.

I agree it's still larger than it should be: having more than
a few hundred bytes on a function usually means that there is
both the risk for actual overflow and general inefficiency if
all the stack data gets accessed as well.

It's probably not actually structure data though, but a
combination of effects:

- 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
- 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.

The good news is that so far my randconfig builds have not
shown any more stack frame warnings on next-20230523 with
bcachefs force-enabled, now 55 builds into the change,
across arm32/arm64/x86 using gcc-15.1.

       Arnd

  reply	other threads:[~2025-05-23 15:17 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-05-22 13:29 riscv gcc-13 allyesconfig error the frame size of 2064 bytes is larger than 2048 bytes [-Werror=frame-larger-than=] Naresh Kamboju
2025-05-22 16:48 ` Kent Overstreet
2025-05-23 13:19   ` Naresh Kamboju
2025-05-23 13:49     ` Arnd Bergmann
2025-05-23 14:08       ` Kent Overstreet
2025-05-23 15:17         ` Arnd Bergmann [this message]
2025-05-23 17:11           ` Kent Overstreet
2025-05-23 18:01             ` Arnd Bergmann
2025-05-25 17:18               ` David Laight
2025-05-25 17:36                 ` Kent Overstreet
2025-05-25 17:47                   ` David Laight
2025-05-25 18:10                     ` Kent Overstreet
2025-05-25 19:25                   ` Steven Rostedt
2025-05-25 20:04                     ` Kent Overstreet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=566aefc9-7cad-4eb8-8eb0-8640d745efa2@app.fastmail.com \
    --to=arnd@arndb.de \
    --cc=anders.roxell@linaro.org \
    --cc=dan.carpenter@linaro.org \
    --cc=kent.overstreet@linux.dev \
    --cc=linux-bcache@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkft-triage@lists.linaro.org \
    --cc=naresh.kamboju@linaro.org \
    --cc=regressions@lists.linux.dev \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox