linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
	Guenter Roeck <linux@roeck-us.net>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	llvm@lists.linux.dev, Nick Desaulniers <ndesaulniers@google.com>
Subject: Re: [PATCH] Enable '-Werror' by default for all kernel builds
Date: Tue, 7 Sep 2021 10:10:10 -0700	[thread overview]
Message-ID: <CAHk-=wgZkQ+eZ02TaCpAWo_ffiLMwA2tYNHyL+B1dQ4YB0qfmA@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a3_Tdc-XVPXrJ69j3S9048uzmVJGrNcvi0T6yr6OrHkPw@mail.gmail.com>

On Tue, Sep 7, 2021 at 2:11 AM Arnd Bergmann <arnd@kernel.org> wrote:
>
> > x86_64-alpine.log:drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dcn_calcs.c:452:13: error: stack frame size (1800) exceeds limit (1280) in function 'dcn_bw_calc_rq_dlg_ttu' [-Werror,-Wframe-larger-than]
> > x86_64-alpine.log:drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn21/display_rq_dlg_calc_21.c:1657:6: error: stack frame size (1336) exceeds limit (1280) in function 'dml21_rq_dlg_get_dlg_reg' [-Werror,-Wframe-larger-than]
> > x86_64-alpine.log:drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn30/display_rq_dlg_calc_30.c:1831:6: error: stack frame size (1352) exceeds limit (1280) in function 'dml30_rq_dlg_get_dlg_reg' [-Werror,-Wframe-larger-than]
> > x86_64-alpine.log:drivers/gpu/drm/amd/amdgpu/../display/dc/dml/dcn31/display_rq_dlg_calc_31.c:1676:6: error: stack frame size (1336) exceeds limit (1280) in function 'dml31_rq_dlg_get_dlg_reg' [-Werror,-Wframe-larger-than]
> > x86_64-alpine.log:drivers/vhost/scsi.c:1831:12: error: stack frame size (1320) exceeds limit (1280) in function 'vhost_scsi_release' [-Werror,-Wframe-larger-than]
> >
> > Another instance where distros lower CONFIG_FRAME_WARN below the 2048
> > default. Again, none look particularly scary but should still probably
> > be dealt with.
>
> I would argue that they are still scary and should be addressed in the
> code, it's just that we don't see them on build bots that use the 2048 byte default.

No, they are scary for another reason entirely: clang is clearly doing
a *HORRIBLE* job with stack usage.

To take that dml30_rq_dlg_get_dlg_reg() function as an example: yes,
it has a few structures on the stack, but gcc allocates 512-720 bytes
of stack space depending on my config.

Not 1280 bytes.

So it's not even *close* to the 1024 byte limit with gcc, much less the 2kB one.

I don't know why clang basically decides to use almost double the
stack space. Maybe it's some other config option that does it, I tried
a fairly normal one and a "almost everythign enabled" one, and
couldn't get close to the reported stack frame size with gcc.

Just to try to make things as close as possible, I tried with the
exact same normal non-debug config (apart from obvious
compiler-dependent things), and picked that dml30_rq_dlg_get_dlg_reg()
function to look at (for no real reason other than that the stack
frame was biggest above.

Gcc did a 720-byte stack frame for that case. Not great, but whatever.

clang did a 1136-byte stack frame for the same thing.

Do I know why? No. I do note that that code is disgusting.

It's passing one of those structs around by value, for example. That's
a 72-byte structure that is copied on the stack due to stupid calling
conventions. Maybe clang generates a few extra temporaries for it as
part of the function call stack setup? Who knows..

                 Linus

  reply	other threads:[~2021-09-07 17:10 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-06 14:26 [PATCH] Enable '-Werror' by default for all kernel builds Guenter Roeck
2021-09-06 16:12 ` Linus Torvalds
2021-09-06 16:18   ` Linus Torvalds
2021-09-06 17:05   ` Guenter Roeck
2021-09-06 23:06     ` Linus Torvalds
2021-09-06 23:49       ` Guenter Roeck
2021-09-07  1:12         ` Linus Torvalds
2021-09-07  2:29           ` Guenter Roeck
2021-09-07 15:50             ` Guenter Roeck
2021-09-07  8:56         ` Arnd Bergmann
2021-09-08  4:28         ` Guenter Roeck
2021-09-08  4:48           ` Al Viro
2021-09-08  5:14             ` Guenter Roeck
2021-09-08  7:11               ` Geert Uytterhoeven
2021-09-08  9:50                 ` Arnd Bergmann
2021-09-08 10:10                   ` Geert Uytterhoeven
2021-09-08 10:21                   ` Geert Uytterhoeven
2021-09-08 12:42                   ` Guenter Roeck
2021-09-08 13:19                     ` Al Viro
2021-09-08 13:54                       ` Guenter Roeck
2021-09-08 14:47                   ` David Laight
2021-09-08  4:55           ` Linus Torvalds
2021-09-08  5:46             ` Guenter Roeck
2021-09-07  5:32       ` Huang Rui
2021-09-07  6:15         ` Christian König
2021-09-07  6:58           ` Geert Uytterhoeven
2021-09-07  2:30   ` Nathan Chancellor
2021-09-07  9:11     ` Arnd Bergmann
2021-09-07 17:10       ` Linus Torvalds [this message]
2021-09-07 17:33         ` Linus Torvalds
2021-09-07 21:07           ` Harry Wentland
2021-09-08  3:52             ` Harry Wentland
2021-09-08  4:41               ` Linus Torvalds
2021-09-09  0:48                 ` Harry Wentland
2021-09-07 17:48         ` Guenter Roeck
2021-09-07 19:12           ` Nathan Chancellor
2021-09-08 20:55       ` Nathan Chancellor
2021-09-08 21:16         ` Guenter Roeck
2021-09-08 21:58           ` Marco Elver
2021-09-09  5:58             ` Christoph Hellwig
2021-09-09  6:07               ` Guenter Roeck
2021-09-09  7:30                 ` Christian König
2021-09-09 14:59                   ` Guenter Roeck
2021-09-09 10:53               ` Marco Elver
2021-09-09 11:00                 ` Arnd Bergmann
2021-09-09 11:43                   ` Marco Elver
2021-09-09 12:55                     ` Arnd Bergmann
2021-09-09 16:53                     ` Linus Torvalds
2021-09-09 16:46               ` Linus Torvalds
2021-09-21 15:41         ` Arnd Bergmann

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='CAHk-=wgZkQ+eZ02TaCpAWo_ffiLMwA2tYNHyL+B1dQ4YB0qfmA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=arnd@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=llvm@lists.linux.dev \
    --cc=nathan@kernel.org \
    --cc=ndesaulniers@google.com \
    /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;
as well as URLs for NNTP newsgroup(s).