* Linux 5.18-rc1 @ 2022-04-03 22:14 Linus Torvalds 2022-04-04 2:22 ` Guenter Roeck 2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven 0 siblings, 2 replies; 29+ messages in thread From: Linus Torvalds @ 2022-04-03 22:14 UTC (permalink / raw) To: Linux Kernel Mailing List So here we are, two weeks later, and the merge window is closed. The full diffstat isn't useful, because this is another of those occasional releases where the AMD drm driver adds those generated register definitions, so the diff is absolutely dominated by register definitions for DCN 3.1.x and MP 13.0.x register definitions. Don't even go look - you'll go blind. Another fairly big chunk of it (but nowhere _near_ the AMD GPU register definitions) is the updates for various Intel performance monitoring event tables. But if you ignore those two areas, things look fairly normal. At that point, it's about 60%driver updates - with GPU updates are still fairly sizable, but now no longer so dominant as to hide everything else. And all the other usual suspects too: networking, sound, media, scsi, pinctrl, clk, etc.. The rest is fairly spread out documentation and devicetree bindings (maybe I should just count that against drivers), architecture updates (biggest part of the diff: nds32 is gone, but there's all the usual x86, arm, arm64, powerpc, parisc, mips and riscv updates). Tooling updates (perf and selftests), and of course all the core kernel updates (filesystem, core, networking, VM). As always, there's _way_ too many changes to list individually, and you're just getting the usual mergelog appended. In fact, at least in pure commits, this has been a bigger merge window than we've had in some time. But let's hope it's all smooth sailing this release. Sure, that will happen. Go test, please, Linus --- Al Viro (1): vfs updates Alex Williamson (1): VFIO updates Alexandre Belloni (2): i3c updates RTC updates Andreas Gruenbacher (2): iomap fixlet gfs2 fixes Andrew Morton (4): updates more updates yet more updates still more updates Arnaldo Carvalho de Melo (2): perf tools updates more perf tools updates Arnd Bergmann (6): asm-generic updates ARM defconfig updates ARM SoC updates ARM driver updates ARM devicetree updates ARM SoC fixes Bartosz Golaszewski (2): gpio updates gpio fixes Benson Leung (1): chrome platform updates Bjorn Andersson (3): rpmsg updates hwspinlock updates remoteproc updates Bjorn Helgaas (2): pci updates pci fix Borislav Petkov (10): EDAC updates x86 cpu feature updates misc x86 updates x86 Kconfig fix x86 paravirt improvement x86 SEV fix x86 SGX updates x86 confidential computing updates x86 cleanups RAS updates Brian Cain (1): hexagon update Casey Schaufler (1): smack update Christian Brauner (2): mount_setattr updates mount attributes PREEMPT_RT update Christoph Hellwig (2): dma-mapping updates more dma-mapping updates Chuck Lever (1): nfsd updates Corey Minyard (1): IPMI updates Damien Le Moal (1): ata updates Dan Williams (3): CXL (Compute Express Link) updates DAX updates libnvdimm updates Daniel Thompson (1): kgdb update Darrick Wong (3): xfs updates xfs fixes vfs fix Dave Airlie (2): drm updates drm fixes Dave Kleikamp (1): jfs updates David Howells (2): watch_queue fixes netfs updates David Sterba (1): btrfs updates Dmitry Torokhov (1): input updates Eric Biederman (3): tasklist_lock optimizations shm ucounts fix ptrace cleanups Eric Biggers (1): fscrypt updates Gao Xiang (1): erofs updates Geert Uytterhoeven (1): m68k updates Greg KH (5): USB/Thunderbolt updates char/misc and other driver updates driver core updates staging driver updates tty/serial driver updates Greg Ungerer (1): m68knommu updates Guenter Roeck (1): hwmon updates Gustavo Silva (1): flexible-array transformations Hans de Goede (1): x86 platform driver updates Helge Deller (3): parisc architecture updates fbdev updates more parisc architecture updates Herbert Xu (2): crypto updates crypto fixes Ilya Dryomov (1): ceph updates Ingo Molnar (3): x86 perf event updates locking updates scheduler updates Jaegeuk Kim (1): f2fs updates Jakub Kicinski (3): networking updates networking fixes more networking updates James Bottomley (1): SCSI updates Jan Kara (2): fsnotify updates reiserfs updates Jarkko Sakkinen (1): tpm updates Jason Donenfeld (2): random number generator updates random number generator fixes Jason Gunthorpe (1): rdma updates Jassi Brar (1): mailbox updates Jens Axboe (12): io_uring updates io_uring statx fixes block updates block driver updates bio_alloc() cleanups NVMe write streams removal bio allocation fix block layer 64-bit data integrity support io_uring fixes block fixes block driver fixes block driver fix Jiri Kosina (1): HID updates Joerg Roedel (1): iommu updates Jonathan Corbet (2): documentation updates more documentation updates Juergen Gross (1): xen updates Kees Cook (8): execve updates pstore updates kernel hardening updates overflow updates bounds fixes FORTIFY_SOURCE updates array-bounds updates hardening updates Lee Jones (2): MFD updates backlight updates Linus Walleij (1): pin control updates Luis Chamberlain (1): module update Mark Brown (4): regmap updates regulator updates spi updates regulator fixes Masahiro Yamada (3): Kbuild update for C11 language base Kbuild updates Kbuild fixes Matthew Wilcox (4): folio updates filesystem folio updates XArray updates more filesystem folio updates Mauro Carvalho Chehab (1): media updates Max Filippov (1): Xtensa updates Michael Ellerman (1): powerpc updates Michael Tsirkin (1): virtio updates Michal Simek (1): microblaze updates Mickaël Salaün (1): landlock updates Miguel Ojeda (1): auxdisplay updates Mike Rapoport (1): memblock updates Mike Snitzer (2): device mapper updates device mapper fixes Mimi Zohar (1): integrity subsystem updates Miquel Raynal (1): MTD updates Namjae Jeon (1): exfat updates Palmer Dabbelt (3): RISC-V updates more RISC-V updates RISC-V fix Paolo Bonzini (2): kvm updates kvm fixes Paul McKenney (2): RCU updates memory model doc update Paul Moore (2): selinux updates audit update Pavel Machek (1): LED updates Peter Zijlstra (1): x86 CET-IBT (Control-Flow-Integrity) support Petr Mladek (2): printk updates livepatching updates Rafael Wysocki (7): ACPI updates power management updates thermal control updates PnP update more power management updates device properties code update more ACPI updates Richard Weinberger (2): JFFS2, UBI and UBIFS updates UML updates Rob Herring (2): devicetree updates devicetree fixes Russell King (3): ARM updates ARM updates ARM fixes Sebastian Reichel (1): power supply and reset updates Shuah Khan (2): Kselftest updates KUnit updates Stafford Horne (1): OpenRISC updates Stephen Boyd (2): clk updates clk fix Steve French (3): cfis updates more cifs updates ksmbd updates Steven Rostedt (4): RTLA tracing tool updates tracing updates trace event string verifier fix more tracing updates Takashi Iwai (2): sound updates sound fixes Ted Ts'o (1): ext4 updates Tejun Heo (2): workqueue updates cgroup updates Tetsuo Handa (1): tomoyo update Thierry Reding (1): pwm updates Thomas Bogendoerfer (2): MIPS updates MIPS fixes Thomas Gleixner (6): x86 PASID support core process handling RT latency updates timer and timekeeping updates interrupt updates RT signal fix x86 fixes Trond Myklebust (1): NFS client updates Ulf Hansson (1): MMC updates Vasily Gorbik (2): s390 updates more s390 updates Vinod Koul (1): dmaengine updates Vlastimil Babka (1): slab updates Wei Liu (1): hyperv updates Will Deacon (1): arm64 updates Wim Van Sebroeck (1): watchdog updates Wolfram Sang (1): i2c updates ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-03 22:14 Linux 5.18-rc1 Linus Torvalds @ 2022-04-04 2:22 ` Guenter Roeck 2022-04-04 3:29 ` Linus Torvalds 2022-04-05 12:19 ` Sudip Mukherjee 2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven 1 sibling, 2 replies; 29+ messages in thread From: Guenter Roeck @ 2022-04-04 2:22 UTC (permalink / raw) To: Linus Torvalds; +Cc: Linux Kernel Mailing List On Sun, Apr 03, 2022 at 03:14:19PM -0700, Linus Torvalds wrote: > So here we are, two weeks later, and the merge window is closed. > > The full diffstat isn't useful, because this is another of those > occasional releases where the AMD drm driver adds those generated > register definitions, so the diff is absolutely dominated by register > definitions for DCN 3.1.x and MP 13.0.x register definitions. Don't > even go look - you'll go blind. > > Another fairly big chunk of it (but nowhere _near_ the AMD GPU > register definitions) is the updates for various Intel performance > monitoring event tables. > > But if you ignore those two areas, things look fairly normal. At that > point, it's about 60%driver updates - with GPU updates are still > fairly sizable, but now no longer so dominant as to hide everything > else. And all the other usual suspects too: networking, sound, media, > scsi, pinctrl, clk, etc.. > > The rest is fairly spread out documentation and devicetree bindings > (maybe I should just count that against drivers), architecture updates > (biggest part of the diff: nds32 is gone, but there's all the usual > x86, arm, arm64, powerpc, parisc, mips and riscv updates). Tooling > updates (perf and selftests), and of course all the core kernel > updates (filesystem, core, networking, VM). > > As always, there's _way_ too many changes to list individually, and > you're just getting the usual mergelog appended. > > In fact, at least in pure commits, this has been a bigger merge window > than we've had in some time. But let's hope it's all smooth sailing > this release. > > Sure, that will happen. > > Go test, please, Build results: total: 151 pass: 142 fail: 9 Failed builds: alpha:allmodconfig arm:allmodconfig csky:allmodconfig i386:allyesconfig i386:allmodconfig mips:allmodconfig parisc:allmodconfig powerpc:ppc32_allmodconfig xtensa:allmodconfig Qemu test results: total: 488 pass: 488 fail: 0 Details below. Guenter --- Building alpha:allmodconfig ... failed -------------- Error log: <stdin>:1517:2: warning: #warning syscall clone3 not implemented [-Wcpp] In file included from include/linux/string.h:20, from include/linux/bitmap.h:11, from include/linux/cpumask.h:12, from include/linux/smp.h:13, from include/linux/lockdep.h:14, from include/linux/spinlock.h:62, from include/linux/wait.h:9, from include/linux/wait_bit.h:8, from include/linux/fs.h:6, from include/linux/highmem.h:5, from include/linux/bvec.h:10, from include/linux/skbuff.h:17, from include/../include/linux/if_arp.h:22, from drivers/staging/r8188eu/core/rtw_br_ext.c:6: In function '__nat25_add_pppoe_tag', inlined from 'nat25_db_handle' at drivers/staging/r8188eu/core/rtw_br_ext.c:479:11: arch/alpha/include/asm/string.h:22:16: error: '__builtin_memcpy' forming offset [40, 2051] is out of the bounds [0, 40] of object 'tag_buf' with type 'unsigned char[40]' Exposed by commit e6148767825c ("Makefile: Enable -Warray-bounds"). Fix at https://lore.kernel.org/lkml/20220403123628.3113382-1-linux@roeck-us.net/ -------------- Building arm:allmodconfig ... failed Building csky:allmodconfig ... failed Building i386:allyesconfig ... failed Building mips:allmodconfig ... failed Building parisc:allmodconfig ... failed Building powerpc:ppc32_allmodconfig ... failed Building xtensa:allmodconfig ... failed -------------- Error log: drivers/misc/habanalabs/common/memory.c: In function 'alloc_device_memory': drivers/misc/habanalabs/common/memory.c:153:49: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] 153 | (u64) gen_pool_dma_alloc_align(vm->dram_pg_pool, Fix at https://lore.kernel.org/lkml/20220401151450.3414694-1-linux@roeck-us.net/ -------------- Building powerpc:ppc32_allmodconfig ... failed -------------- Error log: drivers/tty/serial/mpc52xx_uart.c:967:23: error: initialization of 'unsigned int (*)(struct uart_port *)' from incompatible pointer type 'int (*)(struct uart_port *)' [-Werror=incompatible-pointer-types] 967 | .raw_rx_rdy = mpc5125_psc_raw_rx_rdy, and many similar errors. Caused by commit 18662a1d8f35 ("tty: serial: mpc52xx_uart: make rx/tx hooks return unsigned"). Reported at https://lore.kernel.org/lkml/20220403153607.GA3644508@roeck-us.net/ ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 2:22 ` Guenter Roeck @ 2022-04-04 3:29 ` Linus Torvalds 2022-04-04 4:23 ` Guenter Roeck 2022-04-04 6:01 ` Jiri Slaby 2022-04-05 12:19 ` Sudip Mukherjee 1 sibling, 2 replies; 29+ messages in thread From: Linus Torvalds @ 2022-04-04 3:29 UTC (permalink / raw) To: Guenter Roeck, Larry Finger, Oded Gabbay, Jiri Slaby Cc: Linux Kernel Mailing List, Greg Kroah-Hartman On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <linux@roeck-us.net> wrote: > > In function '__nat25_add_pppoe_tag', > inlined from 'nat25_db_handle' at drivers/staging/r8188eu/core/rtw_br_ext.c:479:11: > arch/alpha/include/asm/string.h:22:16: error: '__builtin_memcpy' forming offset [40, 2051] is out of the bounds [0, 40] of object 'tag_buf' with type 'unsigned char[40]' > > Exposed by commit e6148767825c ("Makefile: Enable -Warray-bounds"). > Fix at https://lore.kernel.org/lkml/20220403123628.3113382-1-linux@roeck-us.net/ Funky. Apparently nobody else does that pppoe_tag thing, and this driver does it wrong on little-endian, which is the common thing to test. Your email that you point to is a bit confused, though, in how it says "when building the driver on a big endian system such as alpha". Alpha is little-endian, not big-endian. Now, why it apparently only warns on alpha, I have absolutely no idea. It should warn on other things too afaik, since that tag->tag_len = htons(MAGIC_CODE_LEN+RTL_RELAY_TAG_LEN+old_tag_len); should be visible not just on alpha. Weird. But your patch looks correct. > Building arm:allmodconfig ... failed > Building csky:allmodconfig ... failed > Building i386:allyesconfig ... failed > Building mips:allmodconfig ... failed > Building parisc:allmodconfig ... failed > Building powerpc:ppc32_allmodconfig ... failed > Building xtensa:allmodconfig ... failed > -------------- > Error log: > drivers/misc/habanalabs/common/memory.c: In function 'alloc_device_memory': > drivers/misc/habanalabs/common/memory.c:153:49: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] > 153 | (u64) gen_pool_dma_alloc_align(vm->dram_pg_pool, > > Fix at https://lore.kernel.org/lkml/20220401151450.3414694-1-linux@roeck-us.net/ Gaah - both of those "(u64)" look pointless. Either the thing is a pointer, in which case that (uinptr_t) - or just (unsigned long) - is the right thing to do, or it's already an integer type, in which case castring it to (u64) just do do that phys_pg_pack->pages[i] = ... assignment seems entirely pointless. So I think the patch should also remove those pointless (u64) casts. Yes, yes, the pages[] array in 'struct hl_vm_phys_pg_pack' 'pages[]' is of u64's, but casting integers like that is just silly. > Error log: > drivers/tty/serial/mpc52xx_uart.c:967:23: error: initialization of 'unsigned int (*)(struct uart_port *)' from incompatible pointer type 'int (*)(struct uart_port *)' [-Werror=incompatible-pointer-types] > 967 | .raw_rx_rdy = mpc5125_psc_raw_rx_rdy, > > and many similar errors. > > Caused by commit 18662a1d8f35 ("tty: serial: mpc52xx_uart: make rx/tx > hooks return unsigned"). Reported at > https://lore.kernel.org/lkml/20220403153607.GA3644508@roeck-us.net/ Jiri - apparently you didn't convert the cases under CONFIG_PPC_MPC512x. Please, people, let's get these silly problems fixed asap, and not have people unaware of them and fixes pending until much later in the rc series? It was painful last release, let's not repeat that mistake. Linus ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 3:29 ` Linus Torvalds @ 2022-04-04 4:23 ` Guenter Roeck 2022-04-04 7:30 ` Ron Economos 2022-04-04 15:32 ` Linus Torvalds 2022-04-04 6:01 ` Jiri Slaby 1 sibling, 2 replies; 29+ messages in thread From: Guenter Roeck @ 2022-04-04 4:23 UTC (permalink / raw) To: Linus Torvalds, Larry Finger, Oded Gabbay, Jiri Slaby Cc: Linux Kernel Mailing List, Greg Kroah-Hartman On 4/3/22 20:29, Linus Torvalds wrote: > On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <linux@roeck-us.net> wrote: >> >> In function '__nat25_add_pppoe_tag', >> inlined from 'nat25_db_handle' at drivers/staging/r8188eu/core/rtw_br_ext.c:479:11: >> arch/alpha/include/asm/string.h:22:16: error: '__builtin_memcpy' forming offset [40, 2051] is out of the bounds [0, 40] of object 'tag_buf' with type 'unsigned char[40]' >> >> Exposed by commit e6148767825c ("Makefile: Enable -Warray-bounds"). >> Fix at https://lore.kernel.org/lkml/20220403123628.3113382-1-linux@roeck-us.net/ > > Funky. Apparently nobody else does that pppoe_tag thing, and this > driver does it wrong on little-endian, which is the common thing to > test. > > Your email that you point to is a bit confused, though, in how it says > "when building the driver on a big endian system such as alpha". > > Alpha is little-endian, not big-endian. > Oops. Sorry, I thought it was big endian. No idea why. I'll update subject and description and resend. > Now, why it apparently only warns on alpha, I have absolutely no idea. > It should warn on other things too afaik, since that > > tag->tag_len = htons(MAGIC_CODE_LEN+RTL_RELAY_TAG_LEN+old_tag_len); > > should be visible not just on alpha. > Maybe htons() and ntohs() are modeled differently on other architectures, and the compiler doesn't see the context ? > Weird. But your patch looks correct. > >> Building arm:allmodconfig ... failed >> Building csky:allmodconfig ... failed >> Building i386:allyesconfig ... failed >> Building mips:allmodconfig ... failed >> Building parisc:allmodconfig ... failed >> Building powerpc:ppc32_allmodconfig ... failed >> Building xtensa:allmodconfig ... failed >> -------------- >> Error log: >> drivers/misc/habanalabs/common/memory.c: In function 'alloc_device_memory': >> drivers/misc/habanalabs/common/memory.c:153:49: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast] >> 153 | (u64) gen_pool_dma_alloc_align(vm->dram_pg_pool, >> >> Fix at https://lore.kernel.org/lkml/20220401151450.3414694-1-linux@roeck-us.net/ > > Gaah - both of those "(u64)" look pointless. > > Either the thing is a pointer, in which case that (uinptr_t) - or just > (unsigned long) - is the right thing to do, or it's already an integer > type, in which case castring it to (u64) just do do that > > phys_pg_pack->pages[i] = ... > > assignment seems entirely pointless. > > So I think the patch should also remove those pointless (u64) casts. > > Yes, yes, the pages[] array in 'struct hl_vm_phys_pg_pack' 'pages[]' > is of u64's, but casting integers like that is just silly. > Double casts are quite common, though. Try 'git grep "(u64)(uintptr_t)"'. But I think you are right, a cast to (uintptr_t) should be sufficient here. I'll resend that patch as well. Guenter ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 4:23 ` Guenter Roeck @ 2022-04-04 7:30 ` Ron Economos 2022-04-04 15:32 ` Linus Torvalds 1 sibling, 0 replies; 29+ messages in thread From: Ron Economos @ 2022-04-04 7:30 UTC (permalink / raw) To: linux; +Cc: Larry.Finger, gregkh, jslaby, linux-kernel, ogabbay, torvalds > On 4/3/22 20:29, Linus Torvalds wrote: > > On Sun, Apr 3, 2022 at 7:22 PM Guenter Roeck <linux@roeck-us.net> wrote: > >> > >> In function '__nat25_add_pppoe_tag', > >> inlined from 'nat25_db_handle' at drivers/staging/r8188eu/core/rtw_br_ext.c:479:11: > >> arch/alpha/include/asm/string.h:22:16: error: '__builtin_memcpy' forming offset [40, 2051] is out of the bounds [0, 40] of object 'tag_buf' with type 'unsigned char[40]' > >> > >> Exposed by commit e6148767825c ("Makefile: Enable -Warray-bounds"). > >> Fix at https://lore.kernel.org/lkml/20220403123628.3113382-1-linux@roeck-us.net/ > > > > Funky. Apparently nobody else does that pppoe_tag thing, and this > > driver does it wrong on little-endian, which is the common thing to > > test. > > > > Your email that you point to is a bit confused, though, in how it says > > "when building the driver on a big endian system such as alpha". > > > > Alpha is little-endian, not big-endian. > > > > Oops. Sorry, I thought it was big endian. No idea why. I'll update > subject and description and resend. > > > Now, why it apparently only warns on alpha, I have absolutely no idea. > > It should warn on other things too afaik, since that > > > > tag->tag_len = htons(MAGIC_CODE_LEN+RTL_RELAY_TAG_LEN+old_tag_len); > > > > should be visible not just on alpha. > > > Maybe htons() and ntohs() are modeled differently on other architectures, > and the compiler doesn't see the context ? > > > Weird. But your patch looks correct. This warning also appears on RISC-V RV64 with gcc 11.2.0. The patch works good. Ron ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 4:23 ` Guenter Roeck 2022-04-04 7:30 ` Ron Economos @ 2022-04-04 15:32 ` Linus Torvalds 2022-04-04 16:21 ` Greg Kroah-Hartman 2022-04-04 16:45 ` Guenter Roeck 1 sibling, 2 replies; 29+ messages in thread From: Linus Torvalds @ 2022-04-04 15:32 UTC (permalink / raw) To: Guenter Roeck Cc: Larry Finger, Oded Gabbay, Jiri Slaby, Linux Kernel Mailing List, Greg Kroah-Hartman On Sun, Apr 3, 2022 at 9:23 PM Guenter Roeck <linux@roeck-us.net> wrote: > > Oops. Sorry, I thought it was big endian. No idea why. I'll update > subject and description and resend. I see your updated patch, but for some reason 'b4' is unhappy about it, with $ b4 am 20220404134338.3276991-1-linux@roeck-us.net causing ✗ [PATCH v3] staging: r8188eu: Fix PPPoE tag insertion on little endian systems --- ✗ BADSIG: DKIM/roeck-us.net your DKIM looks fine on the messages I see, but now that I look at it on the mailing list, I notice that your DKIM really is very wrong, and has a lot of headers that a DKIM signature should *not* have. Your DKIM signature includes header names that are very much for list management, so by definition DKIM will fail for any email you send through a mailing list. Headers like "Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe" etc. The DKIM setup should protect the meaningful headers that matter to the sender, not things that the mail system will validly add when it passes through. So the DKIM header list should be things like ":To:From:Cc:Message-Id:Date:Subject:" Not things like "Sender" or mailing list things. Anyway, I was going to just commit it directly, but with the DKIM verification failing, I was a bit less eager to. And then I noticed that you used "be16_to_cpu()" - which is technically correct - which doesn't match the other code in that file. That driver uses the traditional "htons()" to convert to network byte order. And yes, our naming with "be16_to_cpu()" etc is much more legible and does do the reverse, but it looks very odd to mix the two naming conventions. Either use one or the other, but not a mix. Linus ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 15:32 ` Linus Torvalds @ 2022-04-04 16:21 ` Greg Kroah-Hartman 2022-04-04 16:45 ` Guenter Roeck 1 sibling, 0 replies; 29+ messages in thread From: Greg Kroah-Hartman @ 2022-04-04 16:21 UTC (permalink / raw) To: Linus Torvalds Cc: Guenter Roeck, Larry Finger, Oded Gabbay, Jiri Slaby, Linux Kernel Mailing List On Mon, Apr 04, 2022 at 08:32:16AM -0700, Linus Torvalds wrote: > On Sun, Apr 3, 2022 at 9:23 PM Guenter Roeck <linux@roeck-us.net> wrote: > > > > Oops. Sorry, I thought it was big endian. No idea why. I'll update > > subject and description and resend. > > I see your updated patch, but for some reason 'b4' is unhappy about it, with > > $ b4 am 20220404134338.3276991-1-linux@roeck-us.net > > causing > > ✗ [PATCH v3] staging: r8188eu: Fix PPPoE tag insertion on little > endian systems > --- > ✗ BADSIG: DKIM/roeck-us.net > > your DKIM looks fine on the messages I see, but now that I look at it > on the mailing list, I notice that your DKIM really is very wrong, and > has a lot of headers that a DKIM signature should *not* have. > > Your DKIM signature includes header names that are very much for list > management, so by definition DKIM will fail for any email you send > through a mailing list. Headers like > "Resent-From:Resent-Sender:Resent-To:Resent-Cc > :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe" etc. > > The DKIM setup should protect the meaningful headers that matter to > the sender, not things that the mail system will validly add when it > passes through. > > So the DKIM header list should be things like > ":To:From:Cc:Message-Id:Date:Subject:" > > Not things like "Sender" or mailing list things. > > Anyway, I was going to just commit it directly, but with the DKIM > verification failing, I was a bit less eager to. And then I noticed > that you used "be16_to_cpu()" - which is technically correct - which > doesn't match the other code in that file. I've taken this in my tree now and will get it to you for -rc2 if you don't want to take it. And yes, I see the dkim issue as well, I haven't started complaining about to people yet as lots of people have problem email setups. Should we start pushing back? thanks, greg k-h ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 15:32 ` Linus Torvalds 2022-04-04 16:21 ` Greg Kroah-Hartman @ 2022-04-04 16:45 ` Guenter Roeck 2022-04-04 17:09 ` Linus Torvalds 2022-04-05 21:14 ` Konstantin Ryabitsev 1 sibling, 2 replies; 29+ messages in thread From: Guenter Roeck @ 2022-04-04 16:45 UTC (permalink / raw) To: Linus Torvalds Cc: Larry Finger, Oded Gabbay, Jiri Slaby, Linux Kernel Mailing List, Greg Kroah-Hartman On 4/4/22 08:32, Linus Torvalds wrote: > On Sun, Apr 3, 2022 at 9:23 PM Guenter Roeck <linux@roeck-us.net> wrote: >> >> Oops. Sorry, I thought it was big endian. No idea why. I'll update >> subject and description and resend. > > I see your updated patch, but for some reason 'b4' is unhappy about it, with > > $ b4 am 20220404134338.3276991-1-linux@roeck-us.net > > causing > > ✗ [PATCH v3] staging: r8188eu: Fix PPPoE tag insertion on little > endian systems > --- > ✗ BADSIG: DKIM/roeck-us.net > > your DKIM looks fine on the messages I see, but now that I look at it > on the mailing list, I notice that your DKIM really is very wrong, and > has a lot of headers that a DKIM signature should *not* have. > > Your DKIM signature includes header names that are very much for list > management, so by definition DKIM will fail for any email you send > through a mailing list. Headers like > "Resent-From:Resent-Sender:Resent-To:Resent-Cc > :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe" etc. > > The DKIM setup should protect the meaningful headers that matter to > the sender, not things that the mail system will validly add when it > passes through. > > So the DKIM header list should be things like > ":To:From:Cc:Message-Id:Date:Subject:" > > Not things like "Sender" or mailing list things. I tried to tell my provider, but to no avail. Until now I used gmail, but gmail will disable that ability by end of this month, leaving me in the dark. Lose-lose situation for me. Right now I don't have a useful alternative that doesn't require me to change my e-mail address completely (or setting up my own e-mail server which is a pita). > > Anyway, I was going to just commit it directly, but with the DKIM > verification failing, I was a bit less eager to. And then I noticed > that you used "be16_to_cpu()" - which is technically correct - which > doesn't match the other code in that file. > Another lose-lose situation. Larry tells me I should use be16_to_cpu(), you tell me I should not. Either case, https://lore.kernel.org/r/YkPK/QmLAp3BkygY@sckzor-linux.localdomain is a more complete solution, so you might want to pick that one. Thanks, Guenter ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 16:45 ` Guenter Roeck @ 2022-04-04 17:09 ` Linus Torvalds 2022-04-05 21:14 ` Konstantin Ryabitsev 1 sibling, 0 replies; 29+ messages in thread From: Linus Torvalds @ 2022-04-04 17:09 UTC (permalink / raw) To: Guenter Roeck Cc: Larry Finger, Oded Gabbay, Jiri Slaby, Linux Kernel Mailing List, Greg Kroah-Hartman On Mon, Apr 4, 2022 at 9:45 AM Guenter Roeck <linux@roeck-us.net> wrote: > > I tried to tell my provider, but to no avail. Sad. Email providers that are clueless about email? Incompetent. Linus ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 16:45 ` Guenter Roeck 2022-04-04 17:09 ` Linus Torvalds @ 2022-04-05 21:14 ` Konstantin Ryabitsev 1 sibling, 0 replies; 29+ messages in thread From: Konstantin Ryabitsev @ 2022-04-05 21:14 UTC (permalink / raw) To: Guenter Roeck Cc: Linus Torvalds, Larry Finger, Oded Gabbay, Jiri Slaby, Linux Kernel Mailing List, Greg Kroah-Hartman On Mon, Apr 04, 2022 at 09:45:46AM -0700, Guenter Roeck wrote: > I tried to tell my provider, but to no avail. Until now I used gmail, > but gmail will disable that ability by end of this month, leaving me > in the dark. Lose-lose situation for me. Right now I don't have a > useful alternative that doesn't require me to change my e-mail > address completely (or setting up my own e-mail server which > is a pita). There are hosting providers that are known to work well. Many people happily use fastmail (e.g. Greg KH), and it is known to do All The Right Things when it comes to DKIM/DMARC. -K ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 3:29 ` Linus Torvalds 2022-04-04 4:23 ` Guenter Roeck @ 2022-04-04 6:01 ` Jiri Slaby 1 sibling, 0 replies; 29+ messages in thread From: Jiri Slaby @ 2022-04-04 6:01 UTC (permalink / raw) To: Linus Torvalds, Guenter Roeck, Larry Finger, Oded Gabbay Cc: Linux Kernel Mailing List, Greg Kroah-Hartman On 04. 04. 22, 5:29, Linus Torvalds wrote: >> Error log: >> drivers/tty/serial/mpc52xx_uart.c:967:23: error: initialization of 'unsigned int (*)(struct uart_port *)' from incompatible pointer type 'int (*)(struct uart_port *)' [-Werror=incompatible-pointer-types] >> 967 | .raw_rx_rdy = mpc5125_psc_raw_rx_rdy, >> >> and many similar errors. >> >> Caused by commit 18662a1d8f35 ("tty: serial: mpc52xx_uart: make rx/tx >> hooks return unsigned"). Reported at >> https://lore.kernel.org/lkml/20220403153607.GA3644508@roeck-us.net/ > > Jiri - apparently you didn't convert the cases under CONFIG_PPC_MPC512x. > > Please, people, let's get these silly problems fixed asap, and not > have people unaware of them and fixes pending until much later in the > rc series? It was painful last release, let's not repeat that > mistake. Sure, I wasn't aware of the issue until yesterday -- when Guenter dropped me an e-mail. It passed through all the testing machinery which is unfortunate. (I have a script to cross-compile most of the peculiar tty drivers [1]. That indeed contains "mpc52xx_uart.o powerpc_mpc5200".) The fix was posted as 20220404055122.31194-1-jslaby@suse.cz . [1] https://pastebin.com/UDTsBAaY thanks, -- js suse labs ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-04 2:22 ` Guenter Roeck 2022-04-04 3:29 ` Linus Torvalds @ 2022-04-05 12:19 ` Sudip Mukherjee 2022-04-05 13:18 ` Guenter Roeck 1 sibling, 1 reply; 29+ messages in thread From: Sudip Mukherjee @ 2022-04-05 12:19 UTC (permalink / raw) To: Linus Torvalds Cc: Linus Torvalds, Linux Kernel Mailing List, Guenter Roeck, Jonathan Cameron On Sun, Apr 03, 2022 at 07:22:39PM -0700, Guenter Roeck wrote: > On Sun, Apr 03, 2022 at 03:14:19PM -0700, Linus Torvalds wrote: > > So here we are, two weeks later, and the merge window is closed. > > <snip> > > > > Go test, please, > > Build results: > total: 151 pass: 142 fail: 9 > Failed builds: > alpha:allmodconfig > arm:allmodconfig Apart from the ones Guenter reported, arm imote2_defconfig fails due to: 28f74201e37c ("ARM: pxa: remove Intel Imote2 and Stargate 2 boards") -- Regards Sudip ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Linux 5.18-rc1 2022-04-05 12:19 ` Sudip Mukherjee @ 2022-04-05 13:18 ` Guenter Roeck 0 siblings, 0 replies; 29+ messages in thread From: Guenter Roeck @ 2022-04-05 13:18 UTC (permalink / raw) To: Sudip Mukherjee, Linus Torvalds Cc: Linux Kernel Mailing List, Jonathan Cameron On 4/5/22 05:19, Sudip Mukherjee wrote: > On Sun, Apr 03, 2022 at 07:22:39PM -0700, Guenter Roeck wrote: >> On Sun, Apr 03, 2022 at 03:14:19PM -0700, Linus Torvalds wrote: >>> So here we are, two weeks later, and the merge window is closed. >>> > > <snip> > >>> >>> Go test, please, >> >> Build results: >> total: 151 pass: 142 fail: 9 >> Failed builds: >> alpha:allmodconfig >> arm:allmodconfig > > Apart from the ones Guenter reported, arm imote2_defconfig fails due to: > 28f74201e37c ("ARM: pxa: remove Intel Imote2 and Stargate 2 boards") > Not entirely surprising, since its support was removed with that patch. The error is "arm-linux-gnueabi-ld: no machine record defined", which is consistent with that removal. So the fix would be to remove that configuration file. Guenter ^ permalink raw reply [flat|nested] 29+ messages in thread
* Build regressions/improvements in v5.18-rc1 2022-04-03 22:14 Linux 5.18-rc1 Linus Torvalds 2022-04-04 2:22 ` Guenter Roeck @ 2022-04-04 7:47 ` Geert Uytterhoeven 2022-04-04 8:16 ` Geert Uytterhoeven 1 sibling, 1 reply; 29+ messages in thread From: Geert Uytterhoeven @ 2022-04-04 7:47 UTC (permalink / raw) To: linux-kernel Below is the list of build error/warning regressions/improvements in v5.18-rc1[1] compared to v5.17[2]. Summarized: - build errors: +36/-15 - build warnings: +5/-38 Happy fixing! ;-) Thanks to the linux-next team for providing the build service. [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs) [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs) *** ERRORS *** 36 error regressions: + /kisskb/src/arch/m68k/include/asm/bitops.h: error: array subscript 2 is above array bounds of 'long unsigned int[1]' [-Werror=array-bounds]: => 329:20 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: .cfi_endproc without corresponding .cfi_startproc: => 32 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: bad or irreducible absolute expression: => 16 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: junk at end of line, first unrecognized character is `:': => 16 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `be 0x100(%sr2,%r0)': => 29 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldi 0,%r20': => 30 + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldw 0(%sp),%r31': => 26 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ble 0x100(%sr2,%r0)': => 51, 46 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 0,%r25': => 44 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 1,%r25': => 49 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 173,%r20': => 45, 50 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.callinfo': => 40 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.entry': => 41 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.exit': => 54 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.proc': => 39 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.procend': => 55 + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.stringz': => 76 + /kisskb/src/arch/sparc/kernel/irq_32.c: error: array subscript [16, 79] is outside array bounds of 'struct tt_entry[1]' [-Werror=array-bounds]: => 262:14, 261:46, 259:14, 258:14, 263:14 + /kisskb/src/drivers/gpu/drm/r128/r128_cce.c: error: case label does not reduce to an integer constant: => 417:2, 418:2 + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'X86_VENDOR_AMD' undeclared (first use in this function): => 149:37 + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'struct cpuinfo_um' has no member named 'x86_vendor': => 149:22 + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: control reaches end of non-void function [-Werror=return-type]: => 150:1 + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: 'struct cpuinfo_um' has no member named 'x86_cache_size': => 88:22 + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: control reaches end of non-void function [-Werror=return-type]: => 89:1 + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: implicit declaration of function '__copy_user_nocache' [-Werror=implicit-function-declaration]: => 100:2 + /kisskb/src/drivers/media/platform/nxp/imx-pxp.h: error: initializer element is not constant: => 582:38 + /kisskb/src/drivers/misc/habanalabs/common/memory.c: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]: => 153:49, 153:7 + /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: => 4917:4 + /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: error: case label does not reduce to an integer constant: => 3798:2, 3809:2 + /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: => 1983:2 + /kisskb/src/drivers/tty/serial/mpc52xx_uart.c: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]: => 1004:12, 1005:12, 1006:14, 970:12, 968:16, 971:14, 969:12, 1002:16, 1003:16, 967:16 + /kisskb/src/drivers/usb/typec/tcpm/tcpm.c: error: case label does not reduce to an integer constant: => 4724:3 + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23 + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_402' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38 + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_404' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38 + /kisskb/src/sound/usb/midi.c: error: case label does not reduce to an integer constant: => 1389:2 15 error improvements: - /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1756:13, 1639:13 => - /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1674:29, 1662:29 => - /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct mm_struct *, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1767:21 => - /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1741:29, 1726:29 => - /kisskb/src/arch/sparc/mm/srmmu.c: error: cast between incompatible function types from 'void (*)(struct vm_area_struct *, long unsigned int, long unsigned int)' to 'void (*)(long unsigned int, long unsigned int, long unsigned int, long unsigned int, long unsigned int)' [-Werror=cast-function-type]: 1694:29, 1711:29 => - /kisskb/src/crypto/blake2b_generic.c: error: the frame size of 2288 bytes is larger than 2048 bytes [-Werror=frame-larger-than=]: 109:1 => - /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: assignment makes pointer from integer without a cast [-Werror=int-conversion]: 317:9, 324:9 => - /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit declaration of function 'ioport_map' [-Werror=implicit-function-declaration]: 317:11 => - /kisskb/src/drivers/vfio/pci/vfio_pci_rdwr.c: error: implicit declaration of function 'ioport_unmap' [-Werror=implicit-function-declaration]: 338:15 => - error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `machine_check_common' defined in .text section in arch/powerpc/kernel/head_64.o: (.text+0x3e4) => - error: arch/powerpc/kvm/book3s_64_entry.o: relocation truncated to fit: R_PPC64_REL14 (stub) against symbol `system_reset_common' defined in .text section in arch/powerpc/kernel/head_64.o: (.text+0x3ec) => - error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.init.text': (.head.text+0x5100), (.head.text+0x5040) => - error: arch/sparc/kernel/head_32.o: relocation truncated to fit: R_SPARC_WDISP22 against symbol `leon_smp_cpu_startup' defined in .text section in arch/sparc/kernel/trampoline_32.o: (.init.text+0xa4) => - error: arch/sparc/kernel/process_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.text': (.fixup+0xc), (.fixup+0x4) => - error: arch/sparc/kernel/signal_32.o: relocation truncated to fit: R_SPARC_WDISP22 against `.text': (.fixup+0x10), (.fixup+0x34), (.fixup+0x28), (.fixup+0x4), (.fixup+0x1c) => *** WARNINGS *** 5 warning regressions: + /kisskb/src/arch/m68k/include/asm/string.h: warning: '__builtin_memset' offset [0, 11] is out of the bounds [0, 0] [-Warray-bounds]: => 68:25 + /kisskb/src/arch/s390/kernel/machine_kexec.c: warning: 'memcpy' offset [0, 511] is out of the bounds [0, 0] [-Warray-bounds]: => 57:9 + /kisskb/src/drivers/net/ethernet/i825xx/sun3_82586.c: warning: array subscript 1 is above array bounds of 'volatile struct transmit_cmd_struct *[1]' [-Warray-bounds]: => 989:108, 989:122 + /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: => 5400:40, 5403:43, 5396:40 + modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.: => N/A 38 warning improvements: - modpost: WARNING: modpost: EXPORT symbol "___rw_read_enter" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "___rw_read_exit" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "___rw_read_try" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "___rw_write_enter" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__ashldi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__ashrdi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__copy_1page" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__divdi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__lshrdi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__muldi3" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__ndelay" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "__udelay" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "bzero_1page" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: EXPORT symbol "empty_zero_page" [vmlinux] version ...: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14410): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14428): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14440): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14458): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14470): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14488): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x144a0): Section mismatch in reference from the variable qed_mfw_legacy_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x144f0): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14508): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14520): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14538): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14550): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14568): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14580): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qed/qed.o(.data+0x14598): Section mismatch in reference from the variable qed_mfw_ext_maps to the variable .init.rodata:qed_mfw_legacy_bb_100g: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4790): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47a8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47c0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47d8): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x47f0): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4808): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => - modpost: WARNING: modpost: drivers/net/ethernet/qlogic/qede/qede.o(.data+0x4820): Section mismatch in reference from the variable qede_forced_speed_maps to the variable .init.rodata:qede_forced_speed_100000: N/A => - modpost: WARNING: modpost: vmlinux.o(.text.unlikely+0x4530): Section mismatch in reference from the function __trace_event_discard_commit() to the variable .init.data:initcall_level_names: N/A => Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven @ 2022-04-04 8:16 ` Geert Uytterhoeven 2022-04-04 9:26 ` Dave Chinner ` (2 more replies) 0 siblings, 3 replies; 29+ messages in thread From: Geert Uytterhoeven @ 2022-04-04 8:16 UTC (permalink / raw) To: linux-kernel Cc: linux-m68k, linux-parisc, sparclinux, dri-devel, Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um, linux-media, netdev, linux-wireless, linux-scsi, linux-serial, linux-usb, linux-xfs, alsa-devel, linux-s390 On Mon, 4 Apr 2022, Geert Uytterhoeven wrote: > Below is the list of build error/warning regressions/improvements in > v5.18-rc1[1] compared to v5.17[2]. > > Summarized: > - build errors: +36/-15 > - build warnings: +5/-38 > > Happy fixing! ;-) > > Thanks to the linux-next team for providing the build service. > > [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs) > [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs) > > > *** ERRORS *** > > 36 error regressions: > + /kisskb/src/arch/m68k/include/asm/bitops.h: error: array subscript 2 is above array bounds of 'long unsigned int[1]' [-Werror=array-bounds]: => 329:20 m68k-gcc8/m68k-allmodconfig (assumed gcc8 bug) > + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: .cfi_endproc without corresponding .cfi_startproc: => 32 > + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: bad or irreducible absolute expression: => 16 > + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: junk at end of line, first unrecognized character is `:': => 16 > + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `be 0x100(%sr2,%r0)': => 29 > + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldi 0,%r20': => 30 > + /kisskb/src/arch/parisc/kernel/vdso32/restart_syscall.S: Error: no such instruction: `ldw 0(%sp),%r31': => 26 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ble 0x100(%sr2,%r0)': => 51, 46 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 0,%r25': => 44 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 1,%r25': => 49 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: no such instruction: `ldi 173,%r20': => 45, 50 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.callinfo': => 40 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.entry': => 41 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.exit': => 54 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.proc': => 39 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.procend': => 55 > + /kisskb/src/arch/parisc/kernel/vdso32/sigtramp.S: Error: unknown pseudo-op: `.stringz': => 76 parisc64-gcc8/generic-64bit_defconfig parisc-gcc8/generic-32bit_defconfig parisc-gcc8/parisc-allmodconfig parisc-gcc8/parisc-allnoconfig > + /kisskb/src/arch/sparc/kernel/irq_32.c: error: array subscript [16, 79] is outside array bounds of 'struct tt_entry[1]' [-Werror=array-bounds]: => 262:14, 261:46, 259:14, 258:14, 263:14 sparc64-gcc11/sparc-allmodconfig > + /kisskb/src/drivers/gpu/drm/r128/r128_cce.c: error: case label does not reduce to an integer constant: => 417:2, 418:2 arm64-gcc5.4/arm64-allmodconfig mipsel/mips-allmodconfig powerpc-gcc5/powerpc-allmodconfig powerpc-gcc5/powerpc-allyesconfig powerpc-gcc5/ppc32_allmodconfig powerpc-gcc5/ppc64_book3e_allmodconfig powerpc-gcc5/ppc64le_allmodconfig > + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'X86_VENDOR_AMD' undeclared (first use in this function): => 149:37 > + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: 'struct cpuinfo_um' has no member named 'x86_vendor': => 149:22 > + /kisskb/src/drivers/infiniband/hw/qib/qib_wc_x86_64.c: error: control reaches end of non-void function [-Werror=return-type]: => 150:1 > + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: 'struct cpuinfo_um' has no member named 'x86_cache_size': => 88:22 > + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: control reaches end of non-void function [-Werror=return-type]: => 89:1 > + /kisskb/src/drivers/infiniband/sw/rdmavt/qp.c: error: implicit declaration of function '__copy_user_nocache' [-Werror=implicit-function-declaration]: => 100:2 um-x86_64/um-allmodconfig um-x86_64/um-allyesconfig > + /kisskb/src/drivers/media/platform/nxp/imx-pxp.h: error: initializer element is not constant: => 582:38 arm64-gcc5.4/arm64-allmodconfig powerpc-gcc5/powerpc-allmodconfig > + /kisskb/src/drivers/misc/habanalabs/common/memory.c: error: cast from pointer to integer of different size [-Werror=pointer-to-int-cast]: => 153:49, 153:7 mipsel/mips-allmodconfig mips-gcc8/mips-allmodconfig sparc64/sparc-allmodconfig xtensa-gcc11/xtensa-allmodconfig > + /kisskb/src/drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: error: case label does not reduce to an integer constant: => 4917:4 > + /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: error: case label does not reduce to an integer constant: => 3798:2, 3809:2 arm64-gcc5.4/arm64-allmodconfig powerpc-gcc5/powerpc-allmodconfig powerpc-gcc5/ppc64_book3e_allmodconfig > + /kisskb/src/drivers/scsi/aacraid/commsup.c: error: case label does not reduce to an integer constant: => 1983:2 arm64-gcc5.4/arm64-allmodconfig powerpc-gcc5/powerpc-allmodconfig powerpc-gcc5/ppc64_book3e_allmodconfig powerpc-gcc5/ppc64le_allmodconfig > + /kisskb/src/drivers/tty/serial/mpc52xx_uart.c: error: initialization from incompatible pointer type [-Werror=incompatible-pointer-types]: => 1004:12, 1005:12, 1006:14, 970:12, 968:16, 971:14, 969:12, 1002:16, 1003:16, 967:16 powerpc-gcc5/ppc32_allmodconfig > + /kisskb/src/drivers/usb/typec/tcpm/tcpm.c: error: case label does not reduce to an integer constant: => 4724:3 arm64-gcc5.4/arm64-allmodconfig powerpc-gcc5/powerpc-allmodconfig powerpc-gcc5/ppc64_book3e_allmodconfig > + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23 > + /kisskb/src/sound/usb/midi.c: error: case label does not reduce to an integer constant: => 1389:2 arm64-gcc5.4/arm64-allmodconfig mipsel/mips-allmodconfig powerpc-gcc5/powerpc-allmodconfig powerpc-gcc5/powerpc-allyesconfig powerpc-gcc5/ppc32_allmodconfig powerpc-gcc5/ppc64_book3e_allmodconfig powerpc-gcc5/ppc64le_allmodconfig > + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_402' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38 > + /kisskb/src/include/linux/compiler_types.h: error: call to '__compiletime_assert_404' declared with attribute error: FIELD_PREP: mask is not constant: => 352:38 powerpc-gcc5/powerpc-allmodconfig > *** WARNINGS *** > > 5 warning regressions: > + /kisskb/src/arch/m68k/include/asm/string.h: warning: '__builtin_memset' offset [0, 11] is out of the bounds [0, 0] [-Warray-bounds]: => 68:25 m68k-gcc11/sun3_defconfig > + /kisskb/src/arch/s390/kernel/machine_kexec.c: warning: 'memcpy' offset [0, 511] is out of the bounds [0, 0] [-Warray-bounds]: => 57:9 s390x-gcc11/s390-defconfig > + /kisskb/src/drivers/net/ethernet/i825xx/sun3_82586.c: warning: array subscript 1 is above array bounds of 'volatile struct transmit_cmd_struct *[1]' [-Warray-bounds]: => 989:108, 989:122 m68k-gcc11/sun3_defconfig m68k-gcc8/sun3_defconfig > + /kisskb/src/drivers/scsi/mpt3sas/mpt3sas_base.c: warning: array subscript 'Mpi2SasIOUnitPage1_t {aka struct _MPI2_CONFIG_PAGE_SASIOUNIT_1}[0]' is partly outside array bounds of 'unsigned char[20]' [-Warray-bounds]: => 5400:40, 5403:43, 5396:40 powerpc-gcc11/skiroot_defconfig > + modpost: WARNING: modpost: EXPORT symbol "_mcount" [vmlinux] version generation failed, symbol will not be versioned.: => N/A sparc64-gcc11/sparc64-defconfig sparc64/sparc64-defconfig Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 8:16 ` Geert Uytterhoeven @ 2022-04-04 9:26 ` Dave Chinner 2022-04-04 10:19 ` Geert Uytterhoeven 2022-04-04 18:39 ` Kalle Valo 2022-04-05 6:45 ` Helge Deller 2 siblings, 1 reply; 29+ messages in thread From: Dave Chinner @ 2022-04-04 9:26 UTC (permalink / raw) To: Geert Uytterhoeven Cc: linux-kernel, linux-m68k, linux-parisc, sparclinux, dri-devel, Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um, linux-media, netdev, linux-wireless, linux-scsi, linux-serial, linux-usb, linux-xfs, alsa-devel, linux-s390 On Mon, Apr 04, 2022 at 10:16:08AM +0200, Geert Uytterhoeven wrote: > On Mon, 4 Apr 2022, Geert Uytterhoeven wrote: > > Below is the list of build error/warning regressions/improvements in > > v5.18-rc1[1] compared to v5.17[2]. > > > > Summarized: > > - build errors: +36/-15 > > - build warnings: +5/-38 > > > > Happy fixing! ;-) Well.... > > + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23 Looking at: http://kisskb.ellerman.id.au/kisskb/buildresult/14714961/ The build error is: /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk' TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d " ^ /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags' __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), ^ /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED' { XBF_UNMAPPED, "UNMAPPED" } ^ /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS' __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), ^ /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class': /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */ This doesn't make a whole lotta sense to me. It's blown up in a tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor was any of the surrounding XFS code or contexts. Perhaps something outside XFS changed to cause this on these platforms? Can you bisect this, please? Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 9:26 ` Dave Chinner @ 2022-04-04 10:19 ` Geert Uytterhoeven 2022-04-04 11:45 ` Arnd Bergmann 0 siblings, 1 reply; 29+ messages in thread From: Geert Uytterhoeven @ 2022-04-04 10:19 UTC (permalink / raw) To: Dave Chinner; +Cc: Linux Kernel Mailing List, linux-xfs, Arnd Bergmann Hi Dave CC Arnd On Mon, Apr 4, 2022 at 11:27 AM Dave Chinner <david@fromorbit.com> wrote: > On Mon, Apr 04, 2022 at 10:16:08AM +0200, Geert Uytterhoeven wrote: > > On Mon, 4 Apr 2022, Geert Uytterhoeven wrote: > > > Below is the list of build error/warning regressions/improvements in > > > v5.18-rc1[1] compared to v5.17[2]. > > > > > > Summarized: > > > - build errors: +36/-15 > > > - build warnings: +5/-38 > > > > > > Happy fixing! ;-) > > Well.... > > > > + /kisskb/src/fs/xfs/xfs_buf.h: error: initializer element is not constant: => 46:23 > > Looking at: > > http://kisskb.ellerman.id.au/kisskb/buildresult/14714961/ > > The build error is: > > /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk' > TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d " > ^ > /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags' > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), > ^ > /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED' > { XBF_UNMAPPED, "UNMAPPED" } > ^ > /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS' > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), > ^ > /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class': > /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant > #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */ > > This doesn't make a whole lotta sense to me. It's blown up in a > tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor > was any of the surrounding XFS code or contexts. Perhaps something > outside XFS changed to cause this on these platforms? Upon closer look, all builds showing this issue are using gcc-5... > Can you bisect this, please? Fortunately I still have gcc-5 installed on an older machine, and I could reproduce the issue on amd64 with "make allmodconfig fs/xfs/xfs_trace.o". Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to -std=gnu11"). [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1 Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 10:19 ` Geert Uytterhoeven @ 2022-04-04 11:45 ` Arnd Bergmann 2022-04-04 12:31 ` Arnd Bergmann 2022-04-04 22:16 ` Dave Chinner 0 siblings, 2 replies; 29+ messages in thread From: Arnd Bergmann @ 2022-04-04 11:45 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Dave Chinner, Linux Kernel Mailing List, linux-xfs, Arnd Bergmann On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk' > > TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d " > > ^ > > /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags' > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), > > ^ > > /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED' > > { XBF_UNMAPPED, "UNMAPPED" } > > ^ > > /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS' > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), > > ^ > > /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class': > > /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant > > #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */ > > > > This doesn't make a whole lotta sense to me. It's blown up in a > > tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor > > was any of the surrounding XFS code or contexts. Perhaps something > > outside XFS changed to cause this on these platforms? > > Upon closer look, all builds showing this issue are using gcc-5... > > > Can you bisect this, please? > > Fortunately I still have gcc-5 installed on an older machine, > and I could reproduce the issue on amd64 with > "make allmodconfig fs/xfs/xfs_trace.o". > > Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to > -std=gnu11"). > > [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1 Thanks for the report. I've produced it and can see that the problem is assigning the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is a signed integer overflow, the result is technically undefined behavior, which gcc-5 does not accept as an integer constant. The patch below fixes it for me, but I have not checked if there are any other instances. This could also be done using the 'BIT()' macro if the XFS maintainers prefer: diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h index edcb6254fa6a..762348973e8c 100644 --- a/fs/xfs/xfs_buf.h +++ b/fs/xfs/xfs_buf.h @@ -22,28 +22,28 @@ struct xfs_buf; #define XFS_BUF_DADDR_NULL ((xfs_daddr_t) (-1LL)) -#define XBF_READ (1 << 0) /* buffer intended for reading from device */ -#define XBF_WRITE (1 << 1) /* buffer intended for writing to device */ -#define XBF_READ_AHEAD (1 << 2) /* asynchronous read-ahead */ -#define XBF_NO_IOACCT (1 << 3) /* bypass I/O accounting (non-LRU bufs) */ -#define XBF_ASYNC (1 << 4) /* initiator will not wait for completion */ -#define XBF_DONE (1 << 5) /* all pages in the buffer uptodate */ -#define XBF_STALE (1 << 6) /* buffer has been staled, do not find it */ -#define XBF_WRITE_FAIL (1 << 7) /* async writes have failed on this buffer */ +#define XBF_READ (1ul << 0) /* buffer intended for reading from device */ +#define XBF_WRITE (1ul << 1) /* buffer intended for writing to device */ +#define XBF_READ_AHEAD (1ul << 2) /* asynchronous read-ahead */ +#define XBF_NO_IOACCT (1ul << 3) /* bypass I/O accounting (non-LRU bufs) */ +#define XBF_ASYNC (1ul << 4) /* initiator will not wait for completion */ +#define XBF_DONE (1ul << 5) /* all pages in the buffer uptodate */ +#define XBF_STALE (1ul << 6) /* buffer has been staled, do not find it */ +#define XBF_WRITE_FAIL (1ul << 7) /* async writes have failed on this buffer */ /* buffer type flags for write callbacks */ -#define _XBF_INODES (1 << 16)/* inode buffer */ -#define _XBF_DQUOTS (1 << 17)/* dquot buffer */ -#define _XBF_LOGRECOVERY (1 << 18)/* log recovery buffer */ +#define _XBF_INODES (1ul << 16)/* inode buffer */ +#define _XBF_DQUOTS (1ul << 17)/* dquot buffer */ +#define _XBF_LOGRECOVERY (1ul << 18)/* log recovery buffer */ /* flags used only internally */ -#define _XBF_PAGES (1 << 20)/* backed by refcounted pages */ -#define _XBF_KMEM (1 << 21)/* backed by heap memory */ -#define _XBF_DELWRI_Q (1 << 22)/* buffer on a delwri queue */ +#define _XBF_PAGES (1ul << 20)/* backed by refcounted pages */ +#define _XBF_KMEM (1ul << 21)/* backed by heap memory */ +#define _XBF_DELWRI_Q (1ul << 22)/* buffer on a delwri queue */ /* flags used only as arguments to access routines */ -#define XBF_TRYLOCK (1 << 30)/* lock requested, but do not wait */ -#define XBF_UNMAPPED (1 << 31)/* do not map the buffer */ +#define XBF_TRYLOCK (1ul << 30)/* lock requested, but do not wait */ +#define XBF_UNMAPPED (1ul << 31)/* do not map the buffer */ typedef unsigned int xfs_buf_flags_t; ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 11:45 ` Arnd Bergmann @ 2022-04-04 12:31 ` Arnd Bergmann 2022-04-04 22:16 ` Dave Chinner 1 sibling, 0 replies; 29+ messages in thread From: Arnd Bergmann @ 2022-04-04 12:31 UTC (permalink / raw) To: Arnd Bergmann Cc: Geert Uytterhoeven, Dave Chinner, Linux Kernel Mailing List, linux-xfs On Mon, Apr 4, 2022 at 1:45 PM Arnd Bergmann <arnd@arndb.de> wrote: > On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > Fortunately I still have gcc-5 installed on an older machine, > > and I could reproduce the issue on amd64 with > > "make allmodconfig fs/xfs/xfs_trace.o". > > > > Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to > > -std=gnu11"). > > > > [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1 > > Thanks for the report. I've produced it and can see that the problem > is assigning > the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is > a signed integer overflow, the result is technically undefined behavior, > which gcc-5 does not accept as an integer constant. > > The patch below fixes it for me, but I have not checked if there are any > other instances. There are, this is now the patch to address arm64 allmodconfig: diff --git a/drivers/gpu/drm/r128/r128_drv.h b/drivers/gpu/drm/r128/r128_drv.h index 2e1bc01aa5c9..69b990639b70 100644 --- a/drivers/gpu/drm/r128/r128_drv.h +++ b/drivers/gpu/drm/r128/r128_drv.h @@ -291,18 +291,18 @@ extern long r128_compat_ioctl(struct file *filp, unsigned int cmd, */ #define R128_PM4_BUFFER_OFFSET 0x0700 #define R128_PM4_BUFFER_CNTL 0x0704 -# define R128_PM4_MASK (15 << 28) -# define R128_PM4_NONPM4 (0 << 28) -# define R128_PM4_192PIO (1 << 28) -# define R128_PM4_192BM (2 << 28) -# define R128_PM4_128PIO_64INDBM (3 << 28) -# define R128_PM4_128BM_64INDBM (4 << 28) -# define R128_PM4_64PIO_128INDBM (5 << 28) -# define R128_PM4_64BM_128INDBM (6 << 28) -# define R128_PM4_64PIO_64VCBM_64INDBM (7 << 28) -# define R128_PM4_64BM_64VCBM_64INDBM (8 << 28) -# define R128_PM4_64PIO_64VCPIO_64INDPIO (15 << 28) -# define R128_PM4_BUFFER_CNTL_NOUPDATE (1 << 27) +# define R128_PM4_MASK (15u << 28) +# define R128_PM4_NONPM4 (0u << 28) +# define R128_PM4_192PIO (1u << 28) +# define R128_PM4_192BM (2u << 28) +# define R128_PM4_128PIO_64INDBM (3u << 28) +# define R128_PM4_128BM_64INDBM (4u << 28) +# define R128_PM4_64PIO_128INDBM (5u << 28) +# define R128_PM4_64BM_128INDBM (6u << 28) +# define R128_PM4_64PIO_64VCBM_64INDBM (7u << 28) +# define R128_PM4_64BM_64VCBM_64INDBM (8u << 28) +# define R128_PM4_64PIO_64VCPIO_64INDPIO (15u << 28) +# define R128_PM4_BUFFER_CNTL_NOUPDATE (1u << 27) #define R128_PM4_BUFFER_WM_CNTL 0x0708 # define R128_WMA_SHIFT 0 diff --git a/drivers/media/platform/nxp/imx-pxp.h b/drivers/media/platform/nxp/imx-pxp.h index 44f95c749d2e..83cdb3fd1312 100644 --- a/drivers/media/platform/nxp/imx-pxp.h +++ b/drivers/media/platform/nxp/imx-pxp.h @@ -579,27 +579,27 @@ #define HW_PXP_CSC1_COEF0 (0x000001a0) -#define BM_PXP_CSC1_COEF0_YCBCR_MODE 0x80000000 +#define BM_PXP_CSC1_COEF0_YCBCR_MODE 0x80000000u #define BF_PXP_CSC1_COEF0_YCBCR_MODE(v) \ - (((v) << 31) & BM_PXP_CSC1_COEF0_YCBCR_MODE) -#define BM_PXP_CSC1_COEF0_BYPASS 0x40000000 + (((unsigned)(v) << 31) & BM_PXP_CSC1_COEF0_YCBCR_MODE) +#define BM_PXP_CSC1_COEF0_BYPASS 0x40000000u #define BF_PXP_CSC1_COEF0_BYPASS(v) \ - (((v) << 30) & BM_PXP_CSC1_COEF0_BYPASS) -#define BM_PXP_CSC1_COEF0_RSVD1 0x20000000 + (((unsigned)(v) << 30) & BM_PXP_CSC1_COEF0_BYPASS) +#define BM_PXP_CSC1_COEF0_RSVD1 0x20000000u #define BF_PXP_CSC1_COEF0_RSVD1(v) \ - (((v) << 29) & BM_PXP_CSC1_COEF0_RSVD1) + (((unsigned)(v) << 29) & BM_PXP_CSC1_COEF0_RSVD1) #define BP_PXP_CSC1_COEF0_C0 18 -#define BM_PXP_CSC1_COEF0_C0 0x1FFC0000 +#define BM_PXP_CSC1_COEF0_C0 0x1FFC0000u #define BF_PXP_CSC1_COEF0_C0(v) \ - (((v) << 18) & BM_PXP_CSC1_COEF0_C0) + (((unsigned)(v) << 18) & BM_PXP_CSC1_COEF0_C0) #define BP_PXP_CSC1_COEF0_UV_OFFSET 9 -#define BM_PXP_CSC1_COEF0_UV_OFFSET 0x0003FE00 +#define BM_PXP_CSC1_COEF0_UV_OFFSET 0x0003FE00u #define BF_PXP_CSC1_COEF0_UV_OFFSET(v) \ - (((v) << 9) & BM_PXP_CSC1_COEF0_UV_OFFSET) + (((unsigned)(v) << 9) & BM_PXP_CSC1_COEF0_UV_OFFSET) #define BP_PXP_CSC1_COEF0_Y_OFFSET 0 -#define BM_PXP_CSC1_COEF0_Y_OFFSET 0x000001FF +#define BM_PXP_CSC1_COEF0_Y_OFFSET 0x000001FFu #define BF_PXP_CSC1_COEF0_Y_OFFSET(v) \ - (((v) << 0) & BM_PXP_CSC1_COEF0_Y_OFFSET) + (((unsigned)(v) << 0) & BM_PXP_CSC1_COEF0_Y_OFFSET) #define HW_PXP_CSC1_COEF1 (0x000001b0) diff --git a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h index 5caa75b41b73..7fa901fb5596 100644 --- a/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h +++ b/drivers/net/ethernet/broadcom/bnx2x/bnx2x_reg.h @@ -6196,71 +6196,71 @@ #define HW_LOCK_RESOURCE_RECOVERY_REG 11 #define HW_LOCK_RESOURCE_RESET 5 #define HW_LOCK_RESOURCE_SPIO 2 -#define AEU_INPUTS_ATTN_BITS_ATC_HW_INTERRUPT (0x1<<4) -#define AEU_INPUTS_ATTN_BITS_ATC_PARITY_ERROR (0x1<<5) -#define AEU_INPUTS_ATTN_BITS_BRB_HW_INTERRUPT (0x1<<19) -#define AEU_INPUTS_ATTN_BITS_BRB_PARITY_ERROR (0x1<<18) -#define AEU_INPUTS_ATTN_BITS_CCM_HW_INTERRUPT (0x1<<31) -#define AEU_INPUTS_ATTN_BITS_CCM_PARITY_ERROR (0x1<<30) -#define AEU_INPUTS_ATTN_BITS_CDU_HW_INTERRUPT (0x1<<9) -#define AEU_INPUTS_ATTN_BITS_CDU_PARITY_ERROR (0x1<<8) -#define AEU_INPUTS_ATTN_BITS_CFC_HW_INTERRUPT (0x1<<7) -#define AEU_INPUTS_ATTN_BITS_CFC_PARITY_ERROR (0x1<<6) -#define AEU_INPUTS_ATTN_BITS_CSDM_HW_INTERRUPT (0x1<<29) -#define AEU_INPUTS_ATTN_BITS_CSDM_PARITY_ERROR (0x1<<28) -#define AEU_INPUTS_ATTN_BITS_CSEMI_HW_INTERRUPT (0x1<<1) -#define AEU_INPUTS_ATTN_BITS_CSEMI_PARITY_ERROR (0x1<<0) -#define AEU_INPUTS_ATTN_BITS_DEBUG_PARITY_ERROR (0x1<<18) -#define AEU_INPUTS_ATTN_BITS_DMAE_HW_INTERRUPT (0x1<<11) -#define AEU_INPUTS_ATTN_BITS_DMAE_PARITY_ERROR (0x1<<10) -#define AEU_INPUTS_ATTN_BITS_DOORBELLQ_HW_INTERRUPT (0x1<<13) -#define AEU_INPUTS_ATTN_BITS_DOORBELLQ_PARITY_ERROR (0x1<<12) -#define AEU_INPUTS_ATTN_BITS_GPIO0_FUNCTION_0 (0x1<<2) -#define AEU_INPUTS_ATTN_BITS_IGU_PARITY_ERROR (0x1<<12) -#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_ROM_PARITY (0x1<<28) -#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY (0x1<<31) -#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_RX_PARITY (0x1<<29) -#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY (0x1<<30) -#define AEU_INPUTS_ATTN_BITS_MISC_HW_INTERRUPT (0x1<<15) -#define AEU_INPUTS_ATTN_BITS_MISC_PARITY_ERROR (0x1<<14) -#define AEU_INPUTS_ATTN_BITS_NIG_PARITY_ERROR (0x1<<14) -#define AEU_INPUTS_ATTN_BITS_PARSER_PARITY_ERROR (0x1<<20) -#define AEU_INPUTS_ATTN_BITS_PBCLIENT_HW_INTERRUPT (0x1<<31) -#define AEU_INPUTS_ATTN_BITS_PBCLIENT_PARITY_ERROR (0x1<<30) -#define AEU_INPUTS_ATTN_BITS_PBF_PARITY_ERROR (0x1<<0) -#define AEU_INPUTS_ATTN_BITS_PGLUE_HW_INTERRUPT (0x1<<2) -#define AEU_INPUTS_ATTN_BITS_PGLUE_PARITY_ERROR (0x1<<3) -#define AEU_INPUTS_ATTN_BITS_PXPPCICLOCKCLIENT_HW_INTERRUPT (0x1<<5) -#define AEU_INPUTS_ATTN_BITS_PXPPCICLOCKCLIENT_PARITY_ERROR (0x1<<4) -#define AEU_INPUTS_ATTN_BITS_PXP_HW_INTERRUPT (0x1<<3) -#define AEU_INPUTS_ATTN_BITS_PXP_PARITY_ERROR (0x1<<2) -#define AEU_INPUTS_ATTN_BITS_QM_HW_INTERRUPT (0x1<<3) -#define AEU_INPUTS_ATTN_BITS_QM_PARITY_ERROR (0x1<<2) -#define AEU_INPUTS_ATTN_BITS_SEARCHER_PARITY_ERROR (0x1<<22) -#define AEU_INPUTS_ATTN_BITS_SPIO5 (0x1<<15) -#define AEU_INPUTS_ATTN_BITS_TCM_HW_INTERRUPT (0x1<<27) -#define AEU_INPUTS_ATTN_BITS_TCM_PARITY_ERROR (0x1<<26) -#define AEU_INPUTS_ATTN_BITS_TIMERS_HW_INTERRUPT (0x1<<5) -#define AEU_INPUTS_ATTN_BITS_TIMERS_PARITY_ERROR (0x1<<4) -#define AEU_INPUTS_ATTN_BITS_TSDM_HW_INTERRUPT (0x1<<25) -#define AEU_INPUTS_ATTN_BITS_TSDM_PARITY_ERROR (0x1<<24) -#define AEU_INPUTS_ATTN_BITS_TSEMI_HW_INTERRUPT (0x1<<29) -#define AEU_INPUTS_ATTN_BITS_TSEMI_PARITY_ERROR (0x1<<28) -#define AEU_INPUTS_ATTN_BITS_UCM_HW_INTERRUPT (0x1<<23) -#define AEU_INPUTS_ATTN_BITS_UCM_PARITY_ERROR (0x1<<22) -#define AEU_INPUTS_ATTN_BITS_UPB_HW_INTERRUPT (0x1<<27) -#define AEU_INPUTS_ATTN_BITS_UPB_PARITY_ERROR (0x1<<26) -#define AEU_INPUTS_ATTN_BITS_USDM_HW_INTERRUPT (0x1<<21) -#define AEU_INPUTS_ATTN_BITS_USDM_PARITY_ERROR (0x1<<20) -#define AEU_INPUTS_ATTN_BITS_USEMI_HW_INTERRUPT (0x1<<25) -#define AEU_INPUTS_ATTN_BITS_USEMI_PARITY_ERROR (0x1<<24) -#define AEU_INPUTS_ATTN_BITS_VAUX_PCI_CORE_PARITY_ERROR (0x1<<16) -#define AEU_INPUTS_ATTN_BITS_XCM_HW_INTERRUPT (0x1<<9) -#define AEU_INPUTS_ATTN_BITS_XCM_PARITY_ERROR (0x1<<8) -#define AEU_INPUTS_ATTN_BITS_XSDM_HW_INTERRUPT (0x1<<7) -#define AEU_INPUTS_ATTN_BITS_XSDM_PARITY_ERROR (0x1<<6) -#define AEU_INPUTS_ATTN_BITS_XSEMI_HW_INTERRUPT (0x1<<11) -#define AEU_INPUTS_ATTN_BITS_XSEMI_PARITY_ERROR (0x1<<10) +#define AEU_INPUTS_ATTN_BITS_ATC_HW_INTERRUPT BIT(4) +#define AEU_INPUTS_ATTN_BITS_ATC_PARITY_ERROR BIT(5) +#define AEU_INPUTS_ATTN_BITS_BRB_HW_INTERRUPT BIT(19) +#define AEU_INPUTS_ATTN_BITS_BRB_PARITY_ERROR BIT(18) +#define AEU_INPUTS_ATTN_BITS_CCM_HW_INTERRUPT BIT(31) +#define AEU_INPUTS_ATTN_BITS_CCM_PARITY_ERROR BIT(30) +#define AEU_INPUTS_ATTN_BITS_CDU_HW_INTERRUPT BIT(9) +#define AEU_INPUTS_ATTN_BITS_CDU_PARITY_ERROR BIT(8) +#define AEU_INPUTS_ATTN_BITS_CFC_HW_INTERRUPT BIT(7) +#define AEU_INPUTS_ATTN_BITS_CFC_PARITY_ERROR BIT(6) +#define AEU_INPUTS_ATTN_BITS_CSDM_HW_INTERRUPT BIT(29) +#define AEU_INPUTS_ATTN_BITS_CSDM_PARITY_ERROR BIT(28) +#define AEU_INPUTS_ATTN_BITS_CSEMI_HW_INTERRUPT BIT(1) +#define AEU_INPUTS_ATTN_BITS_CSEMI_PARITY_ERROR BIT(0) +#define AEU_INPUTS_ATTN_BITS_DEBUG_PARITY_ERROR BIT(18) +#define AEU_INPUTS_ATTN_BITS_DMAE_HW_INTERRUPT BIT(11) +#define AEU_INPUTS_ATTN_BITS_DMAE_PARITY_ERROR BIT(10) +#define AEU_INPUTS_ATTN_BITS_DOORBELLQ_HW_INTERRUPT BIT(13) +#define AEU_INPUTS_ATTN_BITS_DOORBELLQ_PARITY_ERROR BIT(12) +#define AEU_INPUTS_ATTN_BITS_GPIO0_FUNCTION_0 BIT(2) +#define AEU_INPUTS_ATTN_BITS_IGU_PARITY_ERROR BIT(12) +#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_ROM_PARITY BIT(28) +#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY BIT(31) +#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_RX_PARITY BIT(29) +#define AEU_INPUTS_ATTN_BITS_MCP_LATCHED_UMP_TX_PARITY BIT(30) +#define AEU_INPUTS_ATTN_BITS_MISC_HW_INTERRUPT BIT(15) +#define AEU_INPUTS_ATTN_BITS_MISC_PARITY_ERROR BIT(14) +#define AEU_INPUTS_ATTN_BITS_NIG_PARITY_ERROR BIT(14) +#define AEU_INPUTS_ATTN_BITS_PARSER_PARITY_ERROR BIT(20) +#define AEU_INPUTS_ATTN_BITS_PBCLIENT_HW_INTERRUPT BIT(31) +#define AEU_INPUTS_ATTN_BITS_PBCLIENT_PARITY_ERROR BIT(30) +#define AEU_INPUTS_ATTN_BITS_PBF_PARITY_ERROR BIT(0) +#define AEU_INPUTS_ATTN_BITS_PGLUE_HW_INTERRUPT BIT(2) +#define AEU_INPUTS_ATTN_BITS_PGLUE_PARITY_ERROR BIT(3) +#define AEU_INPUTS_ATTN_BITS_PXPPCICLOCKCLIENT_HW_INTERRUPT BIT(5) +#define AEU_INPUTS_ATTN_BITS_PXPPCICLOCKCLIENT_PARITY_ERROR BIT(4) +#define AEU_INPUTS_ATTN_BITS_PXP_HW_INTERRUPT BIT(3) +#define AEU_INPUTS_ATTN_BITS_PXP_PARITY_ERROR BIT(2) +#define AEU_INPUTS_ATTN_BITS_QM_HW_INTERRUPT BIT(3) +#define AEU_INPUTS_ATTN_BITS_QM_PARITY_ERROR BIT(2) +#define AEU_INPUTS_ATTN_BITS_SEARCHER_PARITY_ERROR BIT(22) +#define AEU_INPUTS_ATTN_BITS_SPIO5 BIT(15) +#define AEU_INPUTS_ATTN_BITS_TCM_HW_INTERRUPT BIT(27) +#define AEU_INPUTS_ATTN_BITS_TCM_PARITY_ERROR BIT(26) +#define AEU_INPUTS_ATTN_BITS_TIMERS_HW_INTERRUPT BIT(5) +#define AEU_INPUTS_ATTN_BITS_TIMERS_PARITY_ERROR BIT(4) +#define AEU_INPUTS_ATTN_BITS_TSDM_HW_INTERRUPT BIT(25) +#define AEU_INPUTS_ATTN_BITS_TSDM_PARITY_ERROR BIT(24) +#define AEU_INPUTS_ATTN_BITS_TSEMI_HW_INTERRUPT BIT(29) +#define AEU_INPUTS_ATTN_BITS_TSEMI_PARITY_ERROR BIT(28) +#define AEU_INPUTS_ATTN_BITS_UCM_HW_INTERRUPT BIT(23) +#define AEU_INPUTS_ATTN_BITS_UCM_PARITY_ERROR BIT(22) +#define AEU_INPUTS_ATTN_BITS_UPB_HW_INTERRUPT BIT(27) +#define AEU_INPUTS_ATTN_BITS_UPB_PARITY_ERROR BIT(26) +#define AEU_INPUTS_ATTN_BITS_USDM_HW_INTERRUPT BIT(21) +#define AEU_INPUTS_ATTN_BITS_USDM_PARITY_ERROR BIT(20) +#define AEU_INPUTS_ATTN_BITS_USEMI_HW_INTERRUPT BIT(25) +#define AEU_INPUTS_ATTN_BITS_USEMI_PARITY_ERROR BIT(24) +#define AEU_INPUTS_ATTN_BITS_VAUX_PCI_CORE_PARITY_ERROR BIT(16) +#define AEU_INPUTS_ATTN_BITS_XCM_HW_INTERRUPT BIT(9) +#define AEU_INPUTS_ATTN_BITS_XCM_PARITY_ERROR BIT(8) +#define AEU_INPUTS_ATTN_BITS_XSDM_HW_INTERRUPT BIT(7) +#define AEU_INPUTS_ATTN_BITS_XSDM_PARITY_ERROR BIT(6) +#define AEU_INPUTS_ATTN_BITS_XSEMI_HW_INTERRUPT BIT(11) +#define AEU_INPUTS_ATTN_BITS_XSEMI_PARITY_ERROR BIT(10) #define AEU_INPUTS_ATTN_BITS_GPIO3_FUNCTION_0 (0x1<<5) #define AEU_INPUTS_ATTN_BITS_GPIO3_FUNCTION_1 (0x1<<9) diff --git a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c index ba3c159111d3..a8ec60a0d8a1 100644 --- a/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c +++ b/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c @@ -557,7 +557,7 @@ enum brcmf_sdio_frmtype { BRCMF_SDIO_FT_SUB, }; -#define SDIOD_DRVSTR_KEY(chip, pmu) (((chip) << 16) | (pmu)) +#define SDIOD_DRVSTR_KEY(chip, pmu) (((u32)(chip) << 16) | (pmu)) /* SDIO Pad drive strength to select value mappings */ struct sdiod_drive_str { diff --git a/drivers/net/wireless/mediatek/mt76/mt76x2/pci.c b/drivers/net/wireless/mediatek/mt76/mt76x2/pci.c index 8a22ee581674..ab59a1533c02 100644 --- a/drivers/net/wireless/mediatek/mt76/mt76x2/pci.c +++ b/drivers/net/wireless/mediatek/mt76/mt76x2/pci.c @@ -77,13 +77,13 @@ mt76x2e_probe(struct pci_dev *pdev, const struct pci_device_id *id) /* Fix up ASPM configuration */ /* RG_SSUSB_G1_CDR_BIR_LTR = 0x9 */ - mt76_rmw_field(dev, 0x15a10, 0x1f << 16, 0x9); + mt76_rmw_field(dev, 0x15a10, 0x1fu << 16, 0x9); /* RG_SSUSB_G1_CDR_BIC_LTR = 0xf */ - mt76_rmw_field(dev, 0x15a0c, 0xf << 28, 0xf); + mt76_rmw_field(dev, 0x15a0c, 0xfu << 28, 0xf); /* RG_SSUSB_CDR_BR_PE1D = 0x3 */ - mt76_rmw_field(dev, 0x15c58, 0x3 << 6, 0x3); + mt76_rmw_field(dev, 0x15c58, 0x3u << 6, 0x3); mt76_pci_disable_aspm(pdev); diff --git a/drivers/perf/fsl_imx8_ddr_perf.c b/drivers/perf/fsl_imx8_ddr_perf.c index 94ebc1ecace7..7da764322c28 100644 --- a/drivers/perf/fsl_imx8_ddr_perf.c +++ b/drivers/perf/fsl_imx8_ddr_perf.c @@ -24,12 +24,12 @@ #define CNTL_OVER 0x1 #define CNTL_CLEAR 0x2 #define CNTL_EN 0x4 -#define CNTL_EN_MASK 0xFFFFFFFB -#define CNTL_CLEAR_MASK 0xFFFFFFFD -#define CNTL_OVER_MASK 0xFFFFFFFE +#define CNTL_EN_MASK 0xFFFFFFFBu +#define CNTL_CLEAR_MASK 0xFFFFFFFDu +#define CNTL_OVER_MASK 0xFFFFFFFEu #define CNTL_CSV_SHIFT 24 -#define CNTL_CSV_MASK (0xFF << CNTL_CSV_SHIFT) +#define CNTL_CSV_MASK (0xFFu << CNTL_CSV_SHIFT) #define EVENT_CYCLES_ID 0 #define EVENT_CYCLES_COUNTER 0 @@ -416,7 +416,7 @@ static void ddr_perf_counter_enable(struct ddr_pmu *pmu, int config, int counter, bool enable) { u8 reg = counter * 4 + COUNTER_CNTL; - int val; + u32 val; if (enable) { /* diff --git a/drivers/scsi/aacraid/aacraid.h b/drivers/scsi/aacraid/aacraid.h index f849e7c9d428..9df966c6558a 100644 --- a/drivers/scsi/aacraid/aacraid.h +++ b/drivers/scsi/aacraid/aacraid.h @@ -116,12 +116,12 @@ enum { #define get_target_number(x) (x%AAC_MAX_TARGETS) /* Thor AIF events */ -#define SA_AIF_HOTPLUG (1<<1) -#define SA_AIF_HARDWARE (1<<2) -#define SA_AIF_PDEV_CHANGE (1<<4) -#define SA_AIF_LDEV_CHANGE (1<<5) -#define SA_AIF_BPSTAT_CHANGE (1<<30) -#define SA_AIF_BPCFG_CHANGE (1<<31) +#define SA_AIF_HOTPLUG BIT(1) +#define SA_AIF_HARDWARE BIT(2) +#define SA_AIF_PDEV_CHANGE BIT(4) +#define SA_AIF_LDEV_CHANGE BIT(5) +#define SA_AIF_BPSTAT_CHANGE BIT(30) +#define SA_AIF_BPCFG_CHANGE BIT(31) #define HBA_MAX_SG_EMBEDDED 28 #define HBA_MAX_SG_SEPARATE 90 diff --git a/drivers/scsi/ufs/ufshci.h b/drivers/scsi/ufs/ufshci.h index a7ff0e5b5494..afb28efd77c2 100644 --- a/drivers/scsi/ufs/ufshci.h +++ b/drivers/scsi/ufs/ufshci.h @@ -240,8 +240,8 @@ enum { #define UIC_ARG_MPHY_TX_GEN_SEL_INDEX(lane) (lane) #define UIC_ARG_MPHY_RX_GEN_SEL_INDEX(lane) (PA_MAXDATALANES + (lane)) -#define UIC_ARG_MIB_SEL(attr, sel) ((((attr) & 0xFFFF) << 16) |\ - ((sel) & 0xFFFF)) +#define UIC_ARG_MIB_SEL(attr, sel) ((((attr) & 0xFFFFu) << 16) |\ + ((sel) & 0xFFFFu)) #define UIC_ARG_MIB(attr) UIC_ARG_MIB_SEL(attr, 0) #define UIC_ARG_ATTR_TYPE(t) (((t) & 0xFF) << 16) #define UIC_GET_ATTR_ID(v) (((v) >> 16) & 0xFFFF) diff --git a/fs/xfs/xfs_buf.h b/fs/xfs/xfs_buf.h index edcb6254fa6a..762348973e8c 100644 --- a/fs/xfs/xfs_buf.h +++ b/fs/xfs/xfs_buf.h @@ -22,28 +22,28 @@ struct xfs_buf; #define XFS_BUF_DADDR_NULL ((xfs_daddr_t) (-1LL)) -#define XBF_READ (1 << 0) /* buffer intended for reading from device */ -#define XBF_WRITE (1 << 1) /* buffer intended for writing to device */ -#define XBF_READ_AHEAD (1 << 2) /* asynchronous read-ahead */ -#define XBF_NO_IOACCT (1 << 3) /* bypass I/O accounting (non-LRU bufs) */ -#define XBF_ASYNC (1 << 4) /* initiator will not wait for completion */ -#define XBF_DONE (1 << 5) /* all pages in the buffer uptodate */ -#define XBF_STALE (1 << 6) /* buffer has been staled, do not find it */ -#define XBF_WRITE_FAIL (1 << 7) /* async writes have failed on this buffer */ +#define XBF_READ (1ul << 0) /* buffer intended for reading from device */ +#define XBF_WRITE (1ul << 1) /* buffer intended for writing to device */ +#define XBF_READ_AHEAD (1ul << 2) /* asynchronous read-ahead */ +#define XBF_NO_IOACCT (1ul << 3) /* bypass I/O accounting (non-LRU bufs) */ +#define XBF_ASYNC (1ul << 4) /* initiator will not wait for completion */ +#define XBF_DONE (1ul << 5) /* all pages in the buffer uptodate */ +#define XBF_STALE (1ul << 6) /* buffer has been staled, do not find it */ +#define XBF_WRITE_FAIL (1ul << 7) /* async writes have failed on this buffer */ /* buffer type flags for write callbacks */ -#define _XBF_INODES (1 << 16)/* inode buffer */ -#define _XBF_DQUOTS (1 << 17)/* dquot buffer */ -#define _XBF_LOGRECOVERY (1 << 18)/* log recovery buffer */ +#define _XBF_INODES (1ul << 16)/* inode buffer */ +#define _XBF_DQUOTS (1ul << 17)/* dquot buffer */ +#define _XBF_LOGRECOVERY (1ul << 18)/* log recovery buffer */ /* flags used only internally */ -#define _XBF_PAGES (1 << 20)/* backed by refcounted pages */ -#define _XBF_KMEM (1 << 21)/* backed by heap memory */ -#define _XBF_DELWRI_Q (1 << 22)/* buffer on a delwri queue */ +#define _XBF_PAGES (1ul << 20)/* backed by refcounted pages */ +#define _XBF_KMEM (1ul << 21)/* backed by heap memory */ +#define _XBF_DELWRI_Q (1ul << 22)/* buffer on a delwri queue */ /* flags used only as arguments to access routines */ -#define XBF_TRYLOCK (1 << 30)/* lock requested, but do not wait */ -#define XBF_UNMAPPED (1 << 31)/* do not map the buffer */ +#define XBF_TRYLOCK (1ul << 30)/* lock requested, but do not wait */ +#define XBF_UNMAPPED (1ul << 31)/* do not map the buffer */ typedef unsigned int xfs_buf_flags_t; diff --git a/include/linux/mlx5/port.h b/include/linux/mlx5/port.h index 28a928b0684b..f175d5bb601e 100644 --- a/include/linux/mlx5/port.h +++ b/include/linux/mlx5/port.h @@ -141,7 +141,7 @@ enum mlx5_ptys_width { MLX5_PTYS_WIDTH_12X = 1 << 4, }; -#define MLX5E_PROT_MASK(link_mode) (1 << link_mode) +#define MLX5E_PROT_MASK(link_mode) BIT(link_mode) #define MLX5_GET_ETH_PROTO(reg, out, ext, field) \ (ext ? MLX5_GET(reg, out, ext_##field) : \ MLX5_GET(reg, out, field)) diff --git a/include/linux/usb/pd_bdo.h b/include/linux/usb/pd_bdo.h index 033fe3e17141..f0ad5ce8c8a0 100644 --- a/include/linux/usb/pd_bdo.h +++ b/include/linux/usb/pd_bdo.h @@ -7,16 +7,16 @@ #define __LINUX_USB_PD_BDO_H /* BDO : BIST Data Object */ -#define BDO_MODE_RECV (0 << 28) -#define BDO_MODE_TRANSMIT (1 << 28) -#define BDO_MODE_COUNTERS (2 << 28) -#define BDO_MODE_CARRIER0 (3 << 28) -#define BDO_MODE_CARRIER1 (4 << 28) -#define BDO_MODE_CARRIER2 (5 << 28) -#define BDO_MODE_CARRIER3 (6 << 28) -#define BDO_MODE_EYE (7 << 28) -#define BDO_MODE_TESTDATA (8 << 28) +#define BDO_MODE_RECV (0u << 28) +#define BDO_MODE_TRANSMIT (1u << 28) +#define BDO_MODE_COUNTERS (2u << 28) +#define BDO_MODE_CARRIER0 (3u << 28) +#define BDO_MODE_CARRIER1 (4u << 28) +#define BDO_MODE_CARRIER2 (5u << 28) +#define BDO_MODE_CARRIER3 (6u << 28) +#define BDO_MODE_EYE (7u << 28) +#define BDO_MODE_TESTDATA (8u << 28) -#define BDO_MODE_MASK(mode) ((mode) & 0xf0000000) +#define BDO_MODE_MASK(mode) ((mode) & 0xf0000000u) #endif diff --git a/sound/usb/usbaudio.h b/sound/usb/usbaudio.h index 167834133b9b..b8359a0aa008 100644 --- a/sound/usb/usbaudio.h +++ b/sound/usb/usbaudio.h @@ -8,7 +8,7 @@ */ /* handling of USB vendor/product ID pairs as 32-bit numbers */ -#define USB_ID(vendor, product) (((vendor) << 16) | (product)) +#define USB_ID(vendor, product) (((unsigned int)(vendor) << 16) | (product)) #define USB_ID_VENDOR(id) ((id) >> 16) #define USB_ID_PRODUCT(id) ((u16)(id)) ^ permalink raw reply related [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 11:45 ` Arnd Bergmann 2022-04-04 12:31 ` Arnd Bergmann @ 2022-04-04 22:16 ` Dave Chinner 2022-04-05 6:47 ` Geert Uytterhoeven 1 sibling, 1 reply; 29+ messages in thread From: Dave Chinner @ 2022-04-04 22:16 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Geert Uytterhoeven, Linux Kernel Mailing List, linux-xfs On Mon, Apr 04, 2022 at 01:45:05PM +0200, Arnd Bergmann wrote: > On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > > > > /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk' > > > TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d " > > > ^ > > > /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags' > > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), > > > ^ > > > /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED' > > > { XBF_UNMAPPED, "UNMAPPED" } > > > ^ > > > /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS' > > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), > > > ^ > > > /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class': > > > /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant > > > #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */ > > > > > > This doesn't make a whole lotta sense to me. It's blown up in a > > > tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor > > > was any of the surrounding XFS code or contexts. Perhaps something > > > outside XFS changed to cause this on these platforms? > > > > Upon closer look, all builds showing this issue are using gcc-5... > > > > > Can you bisect this, please? > > > > Fortunately I still have gcc-5 installed on an older machine, > > and I could reproduce the issue on amd64 with > > "make allmodconfig fs/xfs/xfs_trace.o". > > > > Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to > > -std=gnu11"). > > > > [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1 > > Thanks for the report. I've produced it and can see that the problem > is assigning > the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is > a signed integer overflow, the result is technically undefined behavior, > which gcc-5 does not accept as an integer constant. > > The patch below fixes it for me, but I have not checked if there are any > other instances. This could also be done using the 'BIT()' macro if the > XFS maintainers prefer: So XFS only uses these flags in unsigned int fields that are typed via: typedef unsigned int xfs_buf_flags_t; So on the surface, declaring the flag values as ULONG and then writing them into a UINT field is not a nice thing to be doing. I really don't want to change the xfs_buf_flags_t type to an unsigned long, because that changes the packing of the first cacheline of the struct xfs_buf and the contents of that cacheline are performance critical for the lookup fastpath.... Looking at __print_flags, the internal array type declaration is: struct trace_print_flags { unsigned long mask; const char *name; }; and that's the source of the problem. I notice __print_flags_u64() exists, but __print_flags_u32() does not. Should it? Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 22:16 ` Dave Chinner @ 2022-04-05 6:47 ` Geert Uytterhoeven 2022-04-05 7:08 ` Arnd Bergmann 0 siblings, 1 reply; 29+ messages in thread From: Geert Uytterhoeven @ 2022-04-05 6:47 UTC (permalink / raw) To: Dave Chinner; +Cc: Arnd Bergmann, Linux Kernel Mailing List, linux-xfs Hi Dave, On Tue, Apr 5, 2022 at 12:16 AM Dave Chinner <david@fromorbit.com> wrote: > On Mon, Apr 04, 2022 at 01:45:05PM +0200, Arnd Bergmann wrote: > > On Mon, Apr 4, 2022 at 12:19 PM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > > > /kisskb/src/fs/xfs/./xfs_trace.h:432:2: note: in expansion of macro 'TP_printk' > > > > TP_printk("dev %d:%d daddr 0x%llx bbcount 0x%x hold %d pincount %d " > > > > ^ > > > > /kisskb/src/fs/xfs/./xfs_trace.h:440:5: note: in expansion of macro '__print_flags' > > > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), > > > > ^ > > > > /kisskb/src/fs/xfs/xfs_buf.h:67:4: note: in expansion of macro 'XBF_UNMAPPED' > > > > { XBF_UNMAPPED, "UNMAPPED" } > > > > ^ > > > > /kisskb/src/fs/xfs/./xfs_trace.h:440:40: note: in expansion of macro 'XFS_BUF_FLAGS' > > > > __print_flags(__entry->flags, "|", XFS_BUF_FLAGS), > > > > ^ > > > > /kisskb/src/fs/xfs/./xfs_trace.h: In function 'trace_raw_output_xfs_buf_flags_class': > > > > /kisskb/src/fs/xfs/xfs_buf.h:46:23: error: initializer element is not constant > > > > #define XBF_UNMAPPED (1 << 31)/* do not map the buffer */ > > > > > > > > This doesn't make a whole lotta sense to me. It's blown up in a > > > > tracepoint macro in XFS that was not changed at all in 5.18-rc1, nor > > > > was any of the surrounding XFS code or contexts. Perhaps something > > > > outside XFS changed to cause this on these platforms? > > > > > > Upon closer look, all builds showing this issue are using gcc-5... > > > > > > > Can you bisect this, please? > > > > > > Fortunately I still have gcc-5 installed on an older machine, > > > and I could reproduce the issue on amd64 with > > > "make allmodconfig fs/xfs/xfs_trace.o". > > > > > > Bisection points to commit e8c07082a810fbb9 ("Kbuild: move to > > > -std=gnu11"). > > > > > > [1] gcc version 5.5.0 20171010 (Ubuntu 5.5.0-12ubuntu1 > > > > Thanks for the report. I've produced it and can see that the problem > > is assigning > > the value of "(1 << 31)" to an 'unsigned long' struct member. Since this is > > a signed integer overflow, the result is technically undefined behavior, > > which gcc-5 does not accept as an integer constant. > > > > The patch below fixes it for me, but I have not checked if there are any > > other instances. This could also be done using the 'BIT()' macro if the > > XFS maintainers prefer: > > So XFS only uses these flags in unsigned int fields that are > typed via: > > typedef unsigned int xfs_buf_flags_t; > > So on the surface, declaring the flag values as ULONG and then writing > them into a UINT field is not a nice thing to be doing. > > I really don't want to change the xfs_buf_flags_t type to an > unsigned long, because that changes the packing of the first > cacheline of the struct xfs_buf and the contents of that cacheline > are performance critical for the lookup fastpath.... Hence just use "1u << n" instead of "1ul << n"? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-05 6:47 ` Geert Uytterhoeven @ 2022-04-05 7:08 ` Arnd Bergmann 2022-04-05 21:05 ` Dave Chinner 0 siblings, 1 reply; 29+ messages in thread From: Arnd Bergmann @ 2022-04-05 7:08 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Dave Chinner, Arnd Bergmann, Linux Kernel Mailing List, linux-xfs ?On Tue, Apr 5, 2022 at 8:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > On Tue, Apr 5, 2022 at 12:16 AM Dave Chinner <david@fromorbit.com> wrote: > > So XFS only uses these flags in unsigned int fields that are > > typed via: > > > > typedef unsigned int xfs_buf_flags_t; > > > > So on the surface, declaring the flag values as ULONG and then writing > > them into a UINT field is not a nice thing to be doing. > > > > I really don't want to change the xfs_buf_flags_t type to an > > unsigned long, because that changes the packing of the first > > cacheline of the struct xfs_buf and the contents of that cacheline > > are performance critical for the lookup fastpath.... > > Hence just use "1u << n" instead of "1ul << n"? Right, that avoids the error as well. I picked '1ul' to match the type of the variable it's assigned to, but as Dave said the intended type is 'u32', so '1u' is better here. > > Looking at __print_flags, the internal array type declaration is: > > > > struct trace_print_flags { > > unsigned long mask; > > const char *name; > > }; > > > > and that's the source of the problem. I notice __print_flags_u64() > > exists, but __print_flags_u32() does not. Should it? It's not the source of the error, as there is no signed integer overflow when assigning an unsigned int to an unsigned long. It may be helpful to add a __print_flags_u32(), but it's unrelated to the problem at hand. Arnd ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-05 7:08 ` Arnd Bergmann @ 2022-04-05 21:05 ` Dave Chinner 0 siblings, 0 replies; 29+ messages in thread From: Dave Chinner @ 2022-04-05 21:05 UTC (permalink / raw) To: Arnd Bergmann; +Cc: Geert Uytterhoeven, Linux Kernel Mailing List, linux-xfs On Tue, Apr 05, 2022 at 09:08:13AM +0200, Arnd Bergmann wrote: > ?On Tue, Apr 5, 2022 at 8:47 AM Geert Uytterhoeven <geert@linux-m68k.org> wrote: > > On Tue, Apr 5, 2022 at 12:16 AM Dave Chinner <david@fromorbit.com> wrote: > > > So XFS only uses these flags in unsigned int fields that are > > > typed via: > > > > > > typedef unsigned int xfs_buf_flags_t; > > > > > > So on the surface, declaring the flag values as ULONG and then writing > > > them into a UINT field is not a nice thing to be doing. > > > > > > I really don't want to change the xfs_buf_flags_t type to an > > > unsigned long, because that changes the packing of the first > > > cacheline of the struct xfs_buf and the contents of that cacheline > > > are performance critical for the lookup fastpath.... > > > > Hence just use "1u << n" instead of "1ul << n"? > > Right, that avoids the error as well. I picked '1ul' to match the type of > the variable it's assigned to, but as Dave said the intended type is > 'u32', so '1u' is better here. Ok, I'll queue up a patch to make this modification. I'll also need to check all the other trace flags fields we print as well, as they likely have the same issue but there's no warnings from them because they don't use the high bit in the 32 bit field yet... > > > Looking at __print_flags, the internal array type declaration is: > > > > > > struct trace_print_flags { > > > unsigned long mask; > > > const char *name; > > > }; > > > > > > and that's the source of the problem. I notice __print_flags_u64() > > > exists, but __print_flags_u32() does not. Should it? > > It's not the source of the error, as there is no signed integer > overflow when assigning an unsigned int to an unsigned long. Thanks for the clarification! Cheers, Dave. -- Dave Chinner david@fromorbit.com ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 8:16 ` Geert Uytterhoeven 2022-04-04 9:26 ` Dave Chinner @ 2022-04-04 18:39 ` Kalle Valo 2022-04-05 6:46 ` Geert Uytterhoeven 2022-04-05 6:45 ` Helge Deller 2 siblings, 1 reply; 29+ messages in thread From: Kalle Valo @ 2022-04-04 18:39 UTC (permalink / raw) To: Geert Uytterhoeven Cc: linux-kernel, linux-m68k, linux-parisc, sparclinux, dri-devel, Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um, linux-media, netdev, linux-wireless, linux-scsi, linux-serial, linux-usb, linux-xfs, alsa-devel, linux-s390 Geert Uytterhoeven <geert@linux-m68k.org> writes: >> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: >> error: case label does not reduce to an integer constant: => 3798:2, >> 3809:2 > > arm64-gcc5.4/arm64-allmodconfig > powerpc-gcc5/powerpc-allmodconfig > powerpc-gcc5/ppc64_book3e_allmodconfig After v5.17 there were two commits to brcmfmac/sdio.c: $ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c ed26edf7bfd9 brcmfmac: Add BCM43454/6 support 6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c I can't see how either of them could cause this warning. Could something else cause this or am I missing something? -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 18:39 ` Kalle Valo @ 2022-04-05 6:46 ` Geert Uytterhoeven 2022-04-05 6:52 ` Kalle Valo 0 siblings, 1 reply; 29+ messages in thread From: Geert Uytterhoeven @ 2022-04-05 6:46 UTC (permalink / raw) To: Kalle Valo Cc: Linux Kernel Mailing List, linux-m68k, Parisc List, sparclinux, DRI Development, Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um, Linux Media Mailing List, netdev, linux-wireless, scsi, open list:SERIAL DRIVERS, USB list, linux-xfs, ALSA Development Mailing List, linux-s390 Hi Kalle, On Mon, Apr 4, 2022 at 8:39 PM Kalle Valo <kvalo@kernel.org> wrote: > Geert Uytterhoeven <geert@linux-m68k.org> writes: > >> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: > >> error: case label does not reduce to an integer constant: => 3798:2, > >> 3809:2 > > > > arm64-gcc5.4/arm64-allmodconfig > > powerpc-gcc5/powerpc-allmodconfig > > powerpc-gcc5/ppc64_book3e_allmodconfig > > After v5.17 there were two commits to brcmfmac/sdio.c: > > $ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > ed26edf7bfd9 brcmfmac: Add BCM43454/6 support > 6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c > > I can't see how either of them could cause this warning. Could something > else cause this or am I missing something? Doh, I should not have reduced the CC list in the xfs subthread... The builds above are all gcc-5 builds, so they are affected by the same issue as XFS: unsigned constants that don't fit in int are lacking a "U" suffix. I assume Arnd's patch for drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c fixes this? https://lore.kernel.org/all/CAK8P3a0wRiS03imdXk2WbGONkSSczEGdE-ue5ubF6UyyDE9dQg@mail.gmail.com Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-05 6:46 ` Geert Uytterhoeven @ 2022-04-05 6:52 ` Kalle Valo 0 siblings, 0 replies; 29+ messages in thread From: Kalle Valo @ 2022-04-05 6:52 UTC (permalink / raw) To: Geert Uytterhoeven Cc: Linux Kernel Mailing List, linux-m68k, Parisc List, sparclinux, DRI Development, Dennis Dalessandro, Mike Marciniszyn, linux-rdma, linux-um, Linux Media Mailing List, netdev, linux-wireless, scsi, open list:SERIAL DRIVERS, USB list, linux-xfs, ALSA Development Mailing List, linux-s390 Geert Uytterhoeven <geert@linux-m68k.org> writes: > On Mon, Apr 4, 2022 at 8:39 PM Kalle Valo <kvalo@kernel.org> wrote: >> Geert Uytterhoeven <geert@linux-m68k.org> writes: >> >> /kisskb/src/drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c: >> >> error: case label does not reduce to an integer constant: => 3798:2, >> >> 3809:2 >> > >> > arm64-gcc5.4/arm64-allmodconfig >> > powerpc-gcc5/powerpc-allmodconfig >> > powerpc-gcc5/ppc64_book3e_allmodconfig >> >> After v5.17 there were two commits to brcmfmac/sdio.c: >> >> $ git log --oneline v5.17.. drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c >> ed26edf7bfd9 brcmfmac: Add BCM43454/6 support >> 6d766d8cb505 brcmfmac: pcie: Declare missing firmware files in pcie.c >> >> I can't see how either of them could cause this warning. Could something >> else cause this or am I missing something? > > Doh, I should not have reduced the CC list in the xfs subthread... > > The builds above are all gcc-5 builds, so they are affected by the same > issue as XFS: unsigned constants that don't fit in int are lacking a > "U" suffix. > > I assume Arnd's patch for > drivers/net/wireless/broadcom/brcm80211/brcmfmac/sdio.c > fixes this? > https://lore.kernel.org/all/CAK8P3a0wRiS03imdXk2WbGONkSSczEGdE-ue5ubF6UyyDE9dQg@mail.gmail.com Great, thanks. I assume Arnd will submit it officially at some point. -- https://patchwork.kernel.org/project/linux-wireless/list/ https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-04 8:16 ` Geert Uytterhoeven 2022-04-04 9:26 ` Dave Chinner 2022-04-04 18:39 ` Kalle Valo @ 2022-04-05 6:45 ` Helge Deller 2022-04-05 6:49 ` Geert Uytterhoeven 2 siblings, 1 reply; 29+ messages in thread From: Helge Deller @ 2022-04-05 6:45 UTC (permalink / raw) To: Geert Uytterhoeven, linux-kernel Cc: linux-parisc, Dennis Dalessandro, Mike Marciniszyn On 4/4/22 10:16, Geert Uytterhoeven wrote: > On Mon, 4 Apr 2022, Geert Uytterhoeven wrote: >> Below is the list of build error/warning regressions/improvements in >> v5.18-rc1[1] compared to v5.17[2]. >> >> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs) >> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs) >> >> *** ERRORS *** > parisc64-gcc8/generic-64bit_defconfig > parisc-gcc8/generic-32bit_defconfig > parisc-gcc8/parisc-allmodconfig > parisc-gcc8/parisc-allnoconfig Someone needs to adjust how the parisc kernel is built on kisskb... The parisc platform got vDSO support, so now the 32- and 64-bit hppa compiler needs to be installed when building (for 64-bit). In addition, it changed how to build a kernel: make ARCH=parisc # to build a 32-bit kernel or make ARCH=parisc64 # to build a 64-bit kernel (before ARCH=parisc was sufficient to build either for 32- or 64-bit). And, in case "CROSS_COMPILE=" is given, you need to give "CROSS32_COMPILE=" as well. It's preferred to leave out both CROSS[32]_COMPILE= parameters and let the environment detect the compilers automatically. They just need to be in $PATH. Who can change that on kisskb ? Helge ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-05 6:45 ` Helge Deller @ 2022-04-05 6:49 ` Geert Uytterhoeven 2022-04-28 7:25 ` Michael Ellerman 0 siblings, 1 reply; 29+ messages in thread From: Geert Uytterhoeven @ 2022-04-05 6:49 UTC (permalink / raw) To: Helge Deller Cc: Linux Kernel Mailing List, Parisc List, Dennis Dalessandro, Mike Marciniszyn, Michael Ellerman Hi Helge, CC Michael On Tue, Apr 5, 2022 at 8:45 AM Helge Deller <deller@gmx.de> wrote: > On 4/4/22 10:16, Geert Uytterhoeven wrote: > > On Mon, 4 Apr 2022, Geert Uytterhoeven wrote: > >> Below is the list of build error/warning regressions/improvements in > >> v5.18-rc1[1] compared to v5.17[2]. > >> > >> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs) > >> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs) > >> > >> *** ERRORS *** > > parisc64-gcc8/generic-64bit_defconfig > > parisc-gcc8/generic-32bit_defconfig > > parisc-gcc8/parisc-allmodconfig > > parisc-gcc8/parisc-allnoconfig > > Someone needs to adjust how the parisc kernel is built on kisskb... > > The parisc platform got vDSO support, so now the 32- and 64-bit > hppa compiler needs to be installed when building (for 64-bit). > > In addition, it changed how to build a kernel: > make ARCH=parisc # to build a 32-bit kernel > or > make ARCH=parisc64 # to build a 64-bit kernel > (before ARCH=parisc was sufficient to build either for 32- or 64-bit). > > And, in case "CROSS_COMPILE=" is given, you need to give "CROSS32_COMPILE=" as well. > It's preferred to leave out both CROSS[32]_COMPILE= parameters and let > the environment detect the compilers automatically. They just need to be in $PATH. > > Who can change that on kisskb ? Michael (CCed). Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@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 ^ permalink raw reply [flat|nested] 29+ messages in thread
* Re: Build regressions/improvements in v5.18-rc1 2022-04-05 6:49 ` Geert Uytterhoeven @ 2022-04-28 7:25 ` Michael Ellerman 0 siblings, 0 replies; 29+ messages in thread From: Michael Ellerman @ 2022-04-28 7:25 UTC (permalink / raw) To: Geert Uytterhoeven, Helge Deller Cc: Linux Kernel Mailing List, Parisc List, Dennis Dalessandro, Mike Marciniszyn Geert Uytterhoeven <geert@linux-m68k.org> writes: > Hi Helge, > > CC Michael > > On Tue, Apr 5, 2022 at 8:45 AM Helge Deller <deller@gmx.de> wrote: >> On 4/4/22 10:16, Geert Uytterhoeven wrote: >> > On Mon, 4 Apr 2022, Geert Uytterhoeven wrote: >> >> Below is the list of build error/warning regressions/improvements in >> >> v5.18-rc1[1] compared to v5.17[2]. >> >> >> >> [1] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/3123109284176b1532874591f7c81f3837bbdc17/ (all 96 configs) >> >> [2] http://kisskb.ellerman.id.au/kisskb/branch/linus/head/f443e374ae131c168a065ea1748feac6b2e76613/ (all 96 configs) >> >> >> >> *** ERRORS *** >> > parisc64-gcc8/generic-64bit_defconfig >> > parisc-gcc8/generic-32bit_defconfig >> > parisc-gcc8/parisc-allmodconfig >> > parisc-gcc8/parisc-allnoconfig >> >> Someone needs to adjust how the parisc kernel is built on kisskb... >> >> The parisc platform got vDSO support, so now the 32- and 64-bit >> hppa compiler needs to be installed when building (for 64-bit). >> >> In addition, it changed how to build a kernel: >> make ARCH=parisc # to build a 32-bit kernel >> or >> make ARCH=parisc64 # to build a 64-bit kernel >> (before ARCH=parisc was sufficient to build either for 32- or 64-bit). >> >> And, in case "CROSS_COMPILE=" is given, you need to give "CROSS32_COMPILE=" as well. >> It's preferred to leave out both CROSS[32]_COMPILE= parameters and let >> the environment detect the compilers automatically. They just need to be in $PATH. >> >> Who can change that on kisskb ? > > Michael (CCed). Hi all, Sorry for the delay, I don't have much time to work on kisskb these days :} I've updated things to work. It required a bit of fiddling because the cross compilers I use from kernel.org don't have hppa and hppa64 in the same prefix. But I just rsync'ed them into a shared directory and that seems to be working. The two parisc configs we have are here, everything recent is green: http://kisskb.ellerman.id.au/kisskb/config/507/ http://kisskb.ellerman.id.au/kisskb/config/508/ I also added gcc11 for parisc. cheers ^ permalink raw reply [flat|nested] 29+ messages in thread
end of thread, other threads:[~2022-04-28 7:25 UTC | newest] Thread overview: 29+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-04-03 22:14 Linux 5.18-rc1 Linus Torvalds 2022-04-04 2:22 ` Guenter Roeck 2022-04-04 3:29 ` Linus Torvalds 2022-04-04 4:23 ` Guenter Roeck 2022-04-04 7:30 ` Ron Economos 2022-04-04 15:32 ` Linus Torvalds 2022-04-04 16:21 ` Greg Kroah-Hartman 2022-04-04 16:45 ` Guenter Roeck 2022-04-04 17:09 ` Linus Torvalds 2022-04-05 21:14 ` Konstantin Ryabitsev 2022-04-04 6:01 ` Jiri Slaby 2022-04-05 12:19 ` Sudip Mukherjee 2022-04-05 13:18 ` Guenter Roeck 2022-04-04 7:47 ` Build regressions/improvements in v5.18-rc1 Geert Uytterhoeven 2022-04-04 8:16 ` Geert Uytterhoeven 2022-04-04 9:26 ` Dave Chinner 2022-04-04 10:19 ` Geert Uytterhoeven 2022-04-04 11:45 ` Arnd Bergmann 2022-04-04 12:31 ` Arnd Bergmann 2022-04-04 22:16 ` Dave Chinner 2022-04-05 6:47 ` Geert Uytterhoeven 2022-04-05 7:08 ` Arnd Bergmann 2022-04-05 21:05 ` Dave Chinner 2022-04-04 18:39 ` Kalle Valo 2022-04-05 6:46 ` Geert Uytterhoeven 2022-04-05 6:52 ` Kalle Valo 2022-04-05 6:45 ` Helge Deller 2022-04-05 6:49 ` Geert Uytterhoeven 2022-04-28 7:25 ` Michael Ellerman
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).