[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <241006B3-699F-44FD-AF85-0133971BCD85@fb.com>
Date: Tue, 16 Nov 2021 21:27:43 +0000
From: Nick Terrell <terrelln@...com>
To: Helge Deller <deller@....de>
CC: Geert Uytterhoeven <geert@...ux-m68k.org>,
Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
Rob Clark <robdclark@...il.com>,
"James E.J. Bottomley" <James.Bottomley@...senpartnership.com>,
Anton Altaparmakov <anton@...era.com>,
Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
"Sergio Paracuellos" <sergio.paracuellos@...il.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Joey Gouly <joey.gouly@....com>,
"Stan Skowronek" <stan@...ellium.com>,
Hector Martin <marcan@...can.st>,
"Andrey Ryabinin" <ryabinin.a.a@...il.com>,
André Almeida <andrealmeid@...labora.com>,
Peter Zijlstra <peterz@...radead.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>,
"open list:GPIO SUBSYSTEM" <linux-gpio@...r.kernel.org>,
Parisc List <linux-parisc@...r.kernel.org>,
linux-arm-msm <linux-arm-msm@...r.kernel.org>,
DRI Development <dri-devel@...ts.freedesktop.org>,
"linux-ntfs-dev@...ts.sourceforge.net"
<linux-ntfs-dev@...ts.sourceforge.net>,
linuxppc-dev <linuxppc-dev@...ts.ozlabs.org>,
"open list:BROADCOM NVRAM DRIVER" <linux-mips@...r.kernel.org>,
linux-pci <linux-pci@...r.kernel.org>,
"Linux Crypto Mailing List" <linux-crypto@...r.kernel.org>,
kasan-dev <kasan-dev@...glegroups.com>
Subject: Re: Build regressions/improvements in v5.16-rc1
> On Nov 16, 2021, at 1:08 PM, Nick Terrell <terrelln@...com> wrote:
>
>
>
>> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller@....de> wrote:
>>
>> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert@...ux-m68k.org> wrote:
>>>> Below is the list of build error/warning regressions/improvements in
>>>> v5.16-rc1[1] compared to v5.15[2].
>>>>
>>>> Summarized:
>>>> - build errors: +20/-13
>>>> - build warnings: +3/-28
>>>>
>>>> Happy fixing! ;-)
>>>>
>>>> Thanks to the linux-next team for providing the build service.
>>>>
>>>> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/fa55b7dcdc43c1aa1ba12bca9d2dd4318c2a0dbf/ (all 90 configs)
>>>> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/8bb7eca972ad531c9b149c0a51ab43a417385813/ (all 90 configs)
>>>>
>>>>
>>>> *** ERRORS ***
>>>>
>>>> 20 error regressions:
>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: expected ':' before '__stringify': => 33:4, 18:4
>>>> + /kisskb/src/arch/parisc/include/asm/jump_label.h: error: label 'l_yes' defined but not used [-Werror=unused-label]: => 38:1, 23:1
>>>
>>> due to static_branch_likely() in crypto/api.c
>>>
>>> parisc-allmodconfig
>>
>> fixed now in the parisc for-next git tree.
>>
>>
>>>> + /kisskb/src/drivers/gpu/drm/msm/msm_drv.h: error: "COND" redefined [-Werror]: => 531
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3252 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 47:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 3360 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 499:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5344 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 334:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_double_fast.c: error: the frame size of 5380 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 354:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 1824 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 372:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 2224 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 204:1
>>>> + /kisskb/src/lib/zstd/compress/zstd_fast.c: error: the frame size of 3800 bytes is larger than 1536 bytes [-Werror=frame-larger-than=]: => 476:1
>>>
>>> parisc-allmodconfig
>>
>> parisc needs much bigger frame sizes, so I'm not astonished here.
>> During the v5.15 cycl I increased it to 1536 (from 1280), so I'm simply tempted to
>> increase it this time to 4096, unless someone has a better idea....
>
> I am working on a patch set to reduce the frame allocations some, but it doesn’t
> get every function below 1536 on parisc with UBSAN. But, in addition to parisc
> needing bigger frame sizes, it seems the gcc-8-hppa-linux-gnu compiler is doing a
> horrendously bad job, especially with -fsanitize=shift enabled.
>
> As an example, one of the functions warned ZSTD_fillDoubleHashTable() [0] takes
> 3252 bytes of stack with -fsanitize=shift enabled (as shown in the first warning on line
> 47 above). It is a trivial function, and there is no reason it should take any more than
> a few bytes of stack allocation. On x86-64 it takes 48 bytes with -fsanitize=shift. On
> gcc-10-hppa-linux-gnu this function only takes 380 bytes of stack space with
> -fsanitize=shift. So it seems like whatever issue is present in gcc-8 they fixed in gcc-10.
>
> On gcc-10-hppa-linux-gnu, after my patch set, I don’t see any -Wframe-larger-than=1536
> errors. So, you could either increase it to 4096 bytes, or switch to gcc-10 for the parisc
> test.
>
> I’ll reply in more detail later today when I put up my patch set to reduce the stack usage.
Zstd has been compiled with -O3 since before this update, and I’ve left it in. However, if
I remove -O3 (which reverts to the default of -O2), the stack space reductions disappear
on parisc. So it seems like gcc-hppa-linux-gnu doesn’t handle -O3 well.
I’ve done some preliminary performance measurements, and -O3 doesn’t seem to be
necessary good performance anymore. So I should be able to remove it. I’ll measure a
bit more carefully, then put a patch up.
> Best,
> Nick Terrell
>
> [0] https://github.com/torvalds/linux/blob/8ab774587903771821b59471cc723bba6d893942/lib/zstd/compress/zstd_double_fast.c#L15-L47
>
>>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2240 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2304 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>>> + /kisskb/src/fs/ntfs/aops.c: error: the frame size of 2320 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: => 1311:1
>>>
>>> powerpc-allmodconfig
>>>
>>>> + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_366' declared with attribute error: FIELD_PREP: value too large for the field: => 335:38
>>>
>>> in drivers/pinctrl/pinctrl-apple-gpio.c
>>>
>>> arm64-allmodconfig (gcc8)
>>>
>>>> + /kisskb/src/include/linux/fortify-string.h: error: call to '__read_overflow' declared with attribute error: detected read beyond size of object (1st parameter): => 263:25, 277:17
>>>
>>> in lib/test_kasan.c
>>>
>>> s390-all{mod,yes}config
>>> arm64-allmodconfig (gcc11)
>>>
>>>> + error: modpost: "mips_cm_is64" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>> + error: modpost: "mips_cm_lock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>> + error: modpost: "mips_cm_unlock_other" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>> + error: modpost: "mips_cpc_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>> + error: modpost: "mips_gcr_base" [drivers/pci/controller/pcie-mt7621.ko] undefined!: => N/A
>>>
>>> mips-allmodconfig
>>>
>>>> 3 warning regressions:
>>>> + <stdin>: warning: #warning syscall futex_waitv not implemented [-Wcpp]: => 1559:2
>>>
>>> powerpc, m68k, mips, s390, parisc (and probably more)
>>
>> Will someone update all of them at once?
>>
>>
>>
>>
>> Helge
>>
>>
>>>> + arch/m68k/configs/multi_defconfig: warning: symbol value 'm' invalid for MCTP: => 322
>>>> + arch/m68k/configs/sun3_defconfig: warning: symbol value 'm' invalid for MCTP: => 295
>>>
>>> Yeah, that happens when symbols are changed from tristate to bool...
>>> Will be fixed in 5.17-rc1, with the next defconfig refresh.
>>>
>>> Gr{oetje,eeting}s,
>>>
>>> Geert
>>>
>>> --
>>> Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org
>>>
>>> In personal conversations with technical people, I call myself a hacker. But
>>> when I'm talking to journalists I just say "programmer" or something like that.
>>> -- Linus Torvalds
Powered by blists - more mailing lists