> On Nov 15, 2021, at 8:44 AM, Helge Deller <deller@xxxxxx> wrote: > > On 11/15/21 17:12, Geert Uytterhoeven wrote: >> On Mon, Nov 15, 2021 at 4:54 PM Geert Uytterhoeven <geert@xxxxxxxxxxxxxx> 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. 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@xxxxxxxxxxxxxx >> >> 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 >> >
