linux-kernel - Re: [PATCH v2] MIPS: Fix MAX_REG_OFFSET and remove zero-length struct member

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <505DF3CB-F7E2-4233-B39E-654FB5BEB811@linux.dev>
Date: Sat, 19 Apr 2025 12:35:38 +0200
From: Thorsten Blum <thorsten.blum@...ux.dev>
To: Huacai Chen <chenhuacai@...nel.org>
Cc: "Maciej W. Rozycki" <macro@...am.me.uk>,
 Thomas Bogendoerfer <tsbogend@...ha.franken.de>,
 Oleg Nesterov <oleg@...hat.com>,
 linux-mips@...r.kernel.org,
 linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2] MIPS: Fix MAX_REG_OFFSET and remove zero-length struct
 member

Hi Huacai,

On 19. Apr 2025, at 04:56, Huacai Chen wrote:
> On Sat, Apr 19, 2025 at 4:22 AM Thorsten Blum wrote:
>> On 18. Apr 2025, at 22:18, Thorsten Blum wrote:
>>> On 18. Apr 2025, at 17:14, Maciej W. Rozycki wrote:
>>>> On Fri, 18 Apr 2025, Thorsten Blum wrote:
>>>>>>> Does regs_get_register() even work for CPU_CAVIUM_OCTEON when accessing
>>>>>>> the last two registers because they're both ULL, not UL? (independent of
>>>>>>> my patch)
>>>>>> 
>>>>>> Or rather two arrays of registers.  With 32-bit configurations their
>>>>>> contents have to be retrieved by pieces.  I don't know if it's handled by
>>>>>> the caller(s) though as I'm not familiar with this interface.
>>>>> 
>>>>> Ah, CPU_CAVIUM_OCTEON seems to be 64-bit only, so there's no difference
>>>>> between UL and ULL. Then both my patch and your suggestion:
>>>> 
>>>> So it seems odd to use `long long int' here, but I can't be bothered to
>>>> check history.  There could be a valid reason or it could be just sloppy
>>>> coding.
>>>> 
>>>>> I still prefer my approach without '__last[0]' because it also silences
>>>>> the following false-positive Coccinelle warning, which is how I stumbled
>>>>> upon this in the first place:
>>>>> 
>>>>> ./ptrace.h:51:15-21: WARNING use flexible-array member instead
>>>> 
>>>> So make `__last' a flexible array instead?  With a separate patch.
>>> 
>>> No, '__last[0]' is a fake flexible array and the Coccinelle warning is
>>> wrong. We should either ignore the warning or silence it by removing the
>>> marker, but turning it into a real flexible array doesn't make sense.
>>> I'd prefer to just remove it from the struct.
>>> 
>>> Stefan or Oleg, do you have any preference?
>> 
>> Sorry, I meant Thomas, not Stefan.
> In my opinion just changing __last[0] to __last[] is OK, no other
> actions needed.

That doesn't fix the value of MAX_REG_OFFSET - you might be missing some
of the context here.

Thanks,
Thorsten