lkml.org 
[lkml]   [2022]   [Apr]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: Linux 5.18-rc1
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

\
 
 \ /
  Last update: 2022-04-04 06:23    [W:0.082 / U:14.888 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site