Re: Linux 5.18-rc1

From: Linus Torvalds <torvalds@linux-foundation.org>
To: Guenter Roeck <linux@roeck-us.net>,
	Larry Finger <Larry.Finger@lwfinger.net>,
	Oded Gabbay <ogabbay@kernel.org>, Jiri Slaby <jslaby@suse.cz>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Subject: Re: Linux 5.18-rc1
Date: Sun, 3 Apr 2022 20:29:41 -0700	[thread overview]
Message-ID: <CAHk-=wimc7V9mi=P+6p2nnctPYtSM55OSPVERUeJor7fkD_EVg@mail.gmail.com> (raw)
In-Reply-To: <20220404022239.GA1186352@roeck-us.net>

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