All of lore.kernel.org
 help / color / mirror / Atom feed
* 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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  8:16     ` Geert Uytterhoeven
  0 siblings, 0 replies; 36+ 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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-04  8:16     ` Geert Uytterhoeven
  0 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-04  8:16 UTC (permalink / raw)
  To: linux-kernel
  Cc: linux-wireless, alsa-devel, linux-usb, linux-scsi, linux-parisc,
	Dennis Dalessandro, linux-rdma, netdev, Mike Marciniszyn,
	linux-um, dri-devel, linux-xfs, linux-m68k, linux-serial,
	sparclinux, linux-s390, linux-media

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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-04  8:16     ` Geert Uytterhoeven
  0 siblings, 0 replies; 36+ 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

_______________________________________________
linux-um mailing list
linux-um@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-um


^ permalink raw reply	[flat|nested] 36+ 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
  -1 siblings, 0 replies; 36+ 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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-04  9:26       ` Dave Chinner
  0 siblings, 0 replies; 36+ messages in thread
From: Dave Chinner @ 2022-04-04  9:26 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: linux-wireless, alsa-devel, linux-usb, linux-scsi, linux-parisc,
	Dennis Dalessandro, linux-rdma, netdev, Mike Marciniszyn,
	linux-um, linux-kernel, dri-devel, linux-xfs, linux-m68k,
	linux-serial, sparclinux, linux-s390, linux-media

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] 36+ 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
  -1 siblings, 1 reply; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
  2022-04-04  8:16     ` Geert Uytterhoeven
@ 2022-04-04 18:39       ` Kalle Valo
  -1 siblings, 0 replies; 36+ messages in thread
From: Kalle Valo @ 2022-04-04 18:39 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: linux-wireless, alsa-devel, linux-usb, linux-scsi, linux-parisc,
	Dennis Dalessandro, linux-rdma, netdev, Mike Marciniszyn,
	linux-um, linux-kernel, dri-devel, linux-xfs, linux-m68k,
	linux-serial, sparclinux, linux-s390, linux-media

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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-04 18:39       ` Kalle Valo
  0 siblings, 0 replies; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
  2022-04-04  8:16     ` Geert Uytterhoeven
                       ` (3 preceding siblings ...)
  (?)
@ 2022-04-05  6:45     ` Helge Deller
  2022-04-05  6:49       ` Geert Uytterhoeven
  -1 siblings, 1 reply; 36+ 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] 36+ 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
  -1 siblings, 0 replies; 36+ 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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-05  6:46         ` Geert Uytterhoeven
  0 siblings, 0 replies; 36+ messages in thread
From: Geert Uytterhoeven @ 2022-04-05  6:46 UTC (permalink / raw)
  To: Kalle Valo
  Cc: linux-wireless, ALSA Development Mailing List, USB list, scsi,
	Parisc List, Dennis Dalessandro, linux-rdma, netdev,
	Mike Marciniszyn, linux-um, Linux Kernel Mailing List,
	DRI Development, linux-xfs, linux-m68k, open list:SERIAL DRIVERS,
	sparclinux, linux-s390, Linux Media Mailing List

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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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
  -1 siblings, 0 replies; 36+ 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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-05  6:52           ` Kalle Valo
  0 siblings, 0 replies; 36+ messages in thread
From: Kalle Valo @ 2022-04-05  6:52 UTC (permalink / raw)
  To: Geert Uytterhoeven
  Cc: linux-wireless, ALSA Development Mailing List, USB list, scsi,
	Parisc List, Dennis Dalessandro, linux-rdma, netdev,
	Mike Marciniszyn, linux-um, Linux Kernel Mailing List,
	DRI Development, linux-xfs, linux-m68k, open list:SERIAL DRIVERS,
	sparclinux, linux-s390, Linux Media Mailing List

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] 36+ messages in thread

* Re: Build regressions/improvements in v5.18-rc1
@ 2022-04-05  6:52           ` Kalle Valo
  0 siblings, 0 replies; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ 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; 36+ 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] 36+ messages in thread

end of thread, other threads:[~2022-04-28  7:25 UTC | newest]

Thread overview: 36+ 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  8:16     ` Geert Uytterhoeven
2022-04-04  8:16     ` Geert Uytterhoeven
2022-04-04  9:26     ` Dave Chinner
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-04 18:39       ` Kalle Valo
2022-04-05  6:46       ` Geert Uytterhoeven
2022-04-05  6:46         ` Geert Uytterhoeven
2022-04-05  6:52         ` Kalle Valo
2022-04-05  6:52           ` Kalle Valo
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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.