From: Nathan Chancellor <nathan@kernel.org>
To: Arnd Bergmann <arnd@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.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>,
Paul Walmsley <paul.walmsley@sifive.com>,
Palmer Dabbelt <palmer@dabbelt.com>,
Albert Ou <aou@eecs.berkeley.edu>,
linux-riscv@lists.infradead.org,
Andrey Ryabinin <ryabinin.a.a@gmail.com>,
Alexander Potapenko <glider@google.com>,
Dmitry Vyukov <dvyukov@google.com>,
Andrey Konovalov <andreyknvl@gmail.com>,
kasan-dev@googlegroups.com
Subject: Re: [PATCH] Enable '-Werror' by default for all kernel builds
Date: Wed, 8 Sep 2021 13:55:00 -0700 [thread overview]
Message-ID: <YTkjJPCdR1VGaaVm@archlinux-ax161> (raw)
In-Reply-To: <CAK8P3a3_Tdc-XVPXrJ69j3S9048uzmVJGrNcvi0T6yr6OrHkPw@mail.gmail.com>
Hi Arnd,
On Tue, Sep 07, 2021 at 11:11:17AM +0200, Arnd Bergmann wrote:
> On Tue, Sep 7, 2021 at 4:32 AM Nathan Chancellor <nathan@kernel.org> wrote:
> >
> > arm32-allmodconfig.log: crypto/wp512.c:782:13: error: stack frame size (1176) exceeds limit (1024) in function 'wp512_process_buffer' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/firmware/tegra/bpmp-debugfs.c:294:12: error: stack frame size (1256) exceeds limit (1024) in function 'bpmp_debug_show' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/firmware/tegra/bpmp-debugfs.c:357:16: error: stack frame size (1264) exceeds limit (1024) in function 'bpmp_debug_store' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3043:6: error: stack frame size (1384) exceeds limit (1024) in function 'bw_calcs' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:77:13: error: stack frame size (5560) exceeds limit (1024) in function 'calculate_bandwidth' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/mtd/chips/cfi_cmdset_0001.c:1872:12: error: stack frame size (1064) exceeds limit (1024) in function 'cfi_intelext_writev' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/ntb/hw/idt/ntb_hw_idt.c:1041:27: error: stack frame size (1032) exceeds limit (1024) in function 'idt_scan_mws' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/staging/fbtft/fbtft-core.c:902:12: error: stack frame size (1072) exceeds limit (1024) in function 'fbtft_init_display_from_property' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/staging/fbtft/fbtft-core.c:992:5: error: stack frame size (1064) exceeds limit (1024) in function 'fbtft_init_display' [-Werror,-Wframe-larger-than]
> > arm32-allmodconfig.log: drivers/staging/rtl8723bs/core/rtw_security.c:1288:5: error: stack frame size (1040) exceeds limit (1024) in function 'rtw_aes_decrypt' [-Werror,-Wframe-larger-than]
> > arm32-fedora.log: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:3043:6: error: stack frame size (1376) exceeds limit (1024) in function 'bw_calcs' [-Werror,-Wframe-larger-than]
> > arm32-fedora.log: drivers/gpu/drm/amd/amdgpu/../display/dc/calcs/dce_calcs.c:77:13: error: stack frame size (5384) exceeds limit (1024) in function 'calculate_bandwidth' [-Werror,-Wframe-larger-than]
> >
> > Aside from the dce_calcs.c warnings, these do not seem too bad. I
> > believe allmodconfig turns on UBSAN but it could also be aggressive
> > inlining by clang. I intend to look at all -Wframe-large-than warnings
> > closely later.
>
> I've had them close to zero in the past, but a couple of new ones came in.
>
> The amdgpu ones are probably not fixable unless they stop using 64-bit
> floats in the kernel for
> random calculations. The crypto/* ones tend to be compiler bugs, but hard to fix
I have started taking a look at these. Most of the allmodconfig ones
appear to be related to CONFIG_KASAN, which is now supported for
CONFIG_ARM.
The two in bpmp-debugfs.c appear regardless of CONFIG_KASAN and it turns
out that you actually submitted a patch for these:
https://lore.kernel.org/r/20201204193714.3134651-1-arnd@kernel.org/
Is it worth resending or pinging that?
The dce_calcs.c ones also appear without CONFIG_KASAN, which you noted
is probably unavoidable.
The other ones only appear with CONFIG_KASAN. I have not investigated
each instance to see exactly how much KASAN makes the stack blow up.
Perhaps it is worth setting the default of CONFIG_FRAME_WARN to a higher
value with clang+COMPILE_TEST+KASAN?
> > It appears that both Arch Linux and Fedora define CONFIG_FRAME_WARN
> > as 1024, below its default of 2048. I am not sure these look particurly
> > scary (although there are some that are rather large that need to be
> > looked at).
>
> For 64-bit, you usually need 1280 bytes stack space to get a
> reasonably clean build,
> anything that uses more than that tends to be a bug in the code but we
> never warned
> about those by default as the default warning limit in defconfig is 2048.
>
> I think the distros using 1024 did that because they use a common base config
> for 32-bit and 64-bit targets.
That is a fair explanation.
> > I suspect this is a backend problem because these do not really appear
> > in any other configurations (might also be something with a sanitizer?)
>
> Agreed. Someone needs to bisect the .config or the compiler flags to see what
> triggers them.
For other people following along, there were a lot of
-Wframe-larger-than instances from RISC-V allmodconfig.
Turns out this is because CONFIG_KASAN_STACK is not respected with
RISC-V. They do not set CONFIG_KASAN_SHADOW_OFFSET so following along in
scripts/Makefile.kasan, CFLAGS_KASAN_SHADOW does not get set to
anything, which means that only '-fsanitize=kernel-address' gets added
to the command line, with none of the other parameters.
I guess there are a couple of ways to tackle this:
1. RISC-V could implement CONFIG_KASAN_SHADOW_OFFSET. They mention that
the logic of KASAN_SHADOW_OFFSET was taken from arm64 but they did
not borrow the Kconfig logic it seems.
2. asan-stack could be hoisted out of the else branch so that it is
always enabled/disabled regardless of KASAN_SHADOW_OFFSET being
defined, which resolved all of these warnings for me in my testing.
I am adding the KASAN and RISC-V folks to CC for this reason.
Cheers,
Nathan
next prev parent reply other threads:[~2021-09-08 20:55 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
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 [this message]
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=YTkjJPCdR1VGaaVm@archlinux-ax161 \
--to=nathan@kernel.org \
--cc=andreyknvl@gmail.com \
--cc=aou@eecs.berkeley.edu \
--cc=arnd@kernel.org \
--cc=dvyukov@google.com \
--cc=glider@google.com \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-riscv@lists.infradead.org \
--cc=linux@roeck-us.net \
--cc=llvm@lists.linux.dev \
--cc=ndesaulniers@google.com \
--cc=palmer@dabbelt.com \
--cc=paul.walmsley@sifive.com \
--cc=ryabinin.a.a@gmail.com \
--cc=torvalds@linux-foundation.org \
/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).