> On Nov 16, 2021, at 1:08 PM, Nick Terrell <terrelln@xxxxxx> wrote: > > > >> 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. 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@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
