Build regressions/improvements in v5.16-rc1

Tue Nov 16 21:27:43 UTC 2021

> On Nov 16, 2021, at 1:08 PM, Nick Terrell <terrelln at fb.com> wrote:
> 
> 
> 
>> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller at gmx.de> wrote:
>> 
>> On 11/15/21 17:12, Geert Uytterhoeven wrote:
>>> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert at linux-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 at linux-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