lkml.org 
[lkml]   [2018]   [Jun]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: linux-next: build warnings after merge of the kbuild tree
On Fri, Jun 1, 2018 at 6:01 AM, Kees Cook <keescook@chromium.org> wrote:
> On Thu, May 31, 2018 at 6:56 PM, Masahiro Yamada
> <yamada.masahiro@socionext.com> wrote:
>> 2018-05-31 12:53 GMT+09:00 Kees Cook <keescook@chromium.org>:
>>> On Wed, May 30, 2018 at 6:26 PM, Kees Cook <keescook@chromium.org> wrote:
>>>> On Wed, May 30, 2018 at 6:12 PM, Masahiro Yamada

>>>>> This has been triggered by the following commit:
>>>>>
>>>>>
>>>>> commit 0e461945f3504e09b8ecf947b6398adce1287a28
>>>>> Author: Masahiro Yamada <yamada.masahiro@socionext.com>
>>>>> Date: Mon May 28 18:22:07 2018 +0900
>>>>>
>>>>> gcc-plugins: allow to enable GCC_PLUGINS for COMPILE_TEST
>>>>>
>>>>>
>>>>>
>>>>> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL was previously disabled
>>>>> for COMPILE_TEST, which is now enabled.
>
> For the moment, can you add "depends on !COMPILE_TEST" to
> CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL in your tree and I'll continue
> to figure out what's happening?
>

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


Arnd

\
 
 \ /
  Last update: 2018-06-02 22:40    [W:0.089 / U:0.216 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site