From: Arnd Bergmann <arnd@arndb.de>
To: Kees Cook <keescook@chromium.org>
Cc: Masahiro Yamada <yamada.masahiro@socionext.com>,
Stephen Rothwell <sfr@canb.auug.org.au>,
Linux-Next Mailing List <linux-next@vger.kernel.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: linux-next: build warnings after merge of the kbuild tree
Date: Mon, 4 Jun 2018 10:39:46 +0200 [thread overview]
Message-ID: <CAK8P3a0K_=dHfsJOkFd5DWMs6i6bxm+2vRbYAc3UEr1bYpNb5g@mail.gmail.com> (raw)
In-Reply-To: <CAK8P3a2h1WZ=Jg4MAHoyCt_YLNRCCBG-JRUfy2qZpQ6trRHesg@mail.gmail.com>
On Sat, Jun 2, 2018 at 10:39 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> I ran into the same thing indepently and bisected it (which led me to
> arrive at this thread).
> One additional bit of information I have is that this happens with all
> versions of
> gcc-7 for me, but not gcc-6.3 or older.
>
> Another finding was the particular instance I noticed:
>
> fs/ext4/inode.c: In function 'ext4_inode_csum':
> fs/ext4/inode.c:83:1: warning: the frame size of 1688 bytes is larger
> than 500 bytes [-Wframe-larger-than=]
>
> comes from inlining the same function multiple times; ext4_inode_csum()
> repeatedly calls ext4_chksum(), which has a struct on the stack. Apparently
> this normally only takes up stack space only once, but when initializing it
> to zero, each instance takes an additional two CRYPTO_MINALIGN bytes
> of stack space (the size of the locally defined structure).
Two more things:
* I believe we still want to leave
CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL depending on
!COMPILE_TEST indefinitely. The reason is that it effectively turns off
-Wmaybe-uninitialized warnings by initializing all structures, so we would
miss those warnings in allmodconfig builds otherwise. Obviously
that shouldn't stop of from fixing the excessive stack usage.
* Here is the full list of instances in which a function stack usage grows
beyond the warning limit with CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL
enabled, after several hundred randconfig builds on arm32/arm64/x86:
drivers/media/dvb-core/dvb_frontend.c: In function 'dvb_frontend_handle_ioctl':
drivers/media/dvb-core/dvb_frontend.c:2647:1: error: the frame size of
1032 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
fs/ext4/super.c: In function 'ext4_group_desc_csum':
fs/ext4/super.c:2306:1: error: the frame size of 1160 bytes is larger
than 1024 bytes [-Werror=frame-larger-than=]
fs/ext4/xattr.c: In function 'ext4_xattr_block_csum':
fs/ext4/xattr.c:147:1: error: the frame size of 1168 bytes is larger
than 1024 bytes [-Werror=frame-larger-than=]
fs/f2fs/inode.c: In function 'f2fs_inode_chksum':
fs/f2fs/inode.c:156:1: error: the frame size of 1424 bytes is larger
than 1024 bytes [-Werror=frame-larger-than=]
net/bluetooth/l2cap_core.c: In function 'l2cap_recv_frame':
net/bluetooth/l2cap_core.c:6976:1: error: the frame size of 2240 bytes
is larger than 2048 bytes [-Werror=frame-larger-than=]
drivers/media/i2c/soc_camera/ov9740.c: In function 'ov9740_set_res':
drivers/media/i2c/soc_camera/ov9740.c:668:1: error: the frame size of
2768 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]
I did not see the brcmsmac warning on my builds though, so presumably there are
some others as well.
Arnd
next prev parent reply other threads:[~2018-06-04 8:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-30 22:40 linux-next: build warnings after merge of the kbuild tree Stephen Rothwell
2018-05-31 1:12 ` Masahiro Yamada
2018-05-31 1:26 ` Kees Cook
2018-05-31 3:53 ` Kees Cook
2018-06-01 1:56 ` Masahiro Yamada
2018-06-01 4:01 ` Kees Cook
2018-06-02 20:39 ` Arnd Bergmann
2018-06-04 8:39 ` Arnd Bergmann [this message]
-- strict thread matches above, loose matches on Subject: below --
2022-06-01 23:28 Stephen Rothwell
2019-09-04 0:13 Stephen Rothwell
2019-09-04 1:00 ` Masahiro Yamada
2019-09-04 6:22 ` Masahiro Yamada
2019-09-04 12:33 ` Stephen Rothwell
2019-09-04 12:32 ` Stephen Rothwell
2017-07-19 0:05 Stephen Rothwell
2016-08-17 1:44 Stephen Rothwell
2016-08-17 12:59 ` Michal Marek
2016-08-18 1:09 ` Nicholas Piggin
2016-08-19 3:38 ` Stephen Rothwell
2016-08-19 5:09 ` Stephen Rothwell
2016-08-19 5:32 ` Nicholas Piggin
2016-08-19 8:37 ` Michal Marek
2016-08-19 10:44 ` Nicholas Piggin
2016-08-22 10:47 ` Nicholas Piggin
2016-08-26 3:58 ` Nicholas Piggin
2016-08-26 6:21 ` Nicholas Mc Guire
2016-06-09 2:22 Stephen Rothwell
2016-06-09 2:56 ` Kees Cook
2016-06-09 4:05 ` Stephen Rothwell
2016-06-09 10:57 ` Michal Marek
2016-06-09 17:37 ` Emese Revfy
2016-06-09 17:58 ` Kees Cook
2016-06-09 11:10 ` Michael Ellerman
2016-06-09 17:42 ` Emese Revfy
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='CAK8P3a0K_=dHfsJOkFd5DWMs6i6bxm+2vRbYAc3UEr1bYpNb5g@mail.gmail.com' \
--to=arnd@arndb.de \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-next@vger.kernel.org \
--cc=sfr@canb.auug.org.au \
--cc=yamada.masahiro@socionext.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).