[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.DEB.2.21.2504181608420.18253@angie.orcam.me.uk>
Date: Fri, 18 Apr 2025 16:14:16 +0100 (BST)
From: "Maciej W. Rozycki" <macro@...am.me.uk>
To: Thorsten Blum <thorsten.blum@...ux.dev>
cc: 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
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.
> Would it make sense to also change the register arrays 'mpl' and 'mtp'
> from ULL to UL? ULL seems unnecessarily confusing to me.
Maybe, but I'm not familiar enough with the Cavium Octeon platform to
decide offhand and I won't dive into it, sorry.
Maciej
Powered by blists - more mailing lists