Re: [PATCH 5.10.y 5.15.y 6.1.y 6.6.y 6.12.y 6.18.y 6.19.y] ARM: clean up the memset64() C wrapper

[Greg KH <greg@kroah.com>]

On Wed, Feb 25, 2026 at 05:03:20PM +0100, Thomas Weißschuh wrote:
> On Wed, Feb 25, 2026 at 07:14:09AM -0800, Greg KH wrote:
> > On Wed, Feb 25, 2026 at 04:08:23PM +0100, Thomas Weißschuh wrote:
> > > On Wed, Feb 25, 2026 at 06:36:13AM -0800, Greg KH wrote:
> > > > On Wed, Feb 25, 2026 at 12:35:09PM +0100, Thomas Weißschuh wrote:
> > > > > [ Upstream commit b52343d1cb47bb27ca32a3f4952cc2fd3cd165bf ]
> > > > > 
> > > > > The current logic to split the 64-bit argument into its 32-bit halves is
> > > > > byte-order specific and a bit clunky.  Use a union instead which is
> > > > > easier to read and works in all cases.
> > > > > 
> > > > > GCC still generates the same machine code.
> > > > > 
> > > > > While at it, rename the arguments of the __memset64() prototype to
> > > > > actually reflect their semantics.
> > > > > 
> > > > > Signed-off-by: Thomas Weißschuh <thomas.weissschuh@linutronix.de>
> > > > > Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
> > > > > Reported-by: Ben Hutchings <ben@decadent.org.uk> # for -stable
> > > > > Link: https://lore.kernel.org/all/1a11526ae3d8664f705b541b8d6ea57b847b49a8.camel@decadent.org.uk/
> > > > > Suggested-by: https://lore.kernel.org/all/aZonkWMwpbFhzDJq@casper.infradead.org/ # for -stable
> > > > > Link: https://lore.kernel.org/all/aZonkWMwpbFhzDJq@casper.infradead.org/
> > > > > ---
> > > > > Hi stable team,
> > > > > 
> > > > > unfortunately the backports of commit 23ea2a4c7232 ("ARM: 9468/1: fix
> > > > > memset64() on big-endian") does not work on 5.10 and 5.15 as
> > > > > CONFIG_CPU_LITTLE_ENDIAN does not exist there, effectively breaking memset64()
> > > > > on little-endian. Please use this variant instead which always works.
> > > > > For consistency I prefer to have it backported to all versions.
> > > > > ---
> > > > >  arch/arm/include/asm/string.h | 14 +++++++++-----
> > > > >  1 file changed, 9 insertions(+), 5 deletions(-)
> > > > > 
> > > > > diff --git a/arch/arm/include/asm/string.h b/arch/arm/include/asm/string.h
> > > > > index b5ad23acb303..369781ec5511 100644
> > > > > --- a/arch/arm/include/asm/string.h
> > > > > +++ b/arch/arm/include/asm/string.h
> > > > > @@ -33,13 +33,17 @@ static inline void *memset32(uint32_t *p, uint32_t v, __kernel_size_t n)
> > > > >  }
> > > > >  
> > > > >  #define __HAVE_ARCH_MEMSET64
> > > > > -extern void *__memset64(uint64_t *, uint32_t low, __kernel_size_t, uint32_t hi);
> > > > > +extern void *__memset64(uint64_t *, uint32_t first, __kernel_size_t, uint32_t second);
> > > > >  static inline void *memset64(uint64_t *p, uint64_t v, __kernel_size_t n)
> > > > >  {
> > > > > -	if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN))
> > > > > -		return __memset64(p, v, n * 8, v >> 32);
> > > > > -	else
> > > > > -		return __memset64(p, v >> 32, n * 8, v);
> > > > > +	union {
> > > > > +		uint64_t val;
> > > > > +		struct {
> > > > > +			uint32_t first, second;
> > > > > +		};
> > > > > +	} word = { .val = v };
> > > > > +
> > > > > +	return __memset64(p, word.first, n * 8, word.second);
> > > > >  }
> > > > >  
> > > > >  #endif
> > > > > 
> > > > > ---
> > > > 
> > > > I don't understand, why is this patch needed at all?  What issue is it
> > > > fixing to require this?
> > > 
> > > memset64() was broken on ARM big-endian. It was fixed in commit 23ea2a4c7232
> > > ("ARM: 9468/1: fix memset64() on big-endian"). That fix was marked with a Fixes:
> > > tag and was backported to all stable kernels. However that fix relies on the
> > > kconfig symbol CONFIG_CPU_LITTLE_ENDIAN (as shown in the diff above).
> > > That kconfig symbol does not exist on 5.10 and 5.15. So now memset64() is
> > > broken on ARM little-endian on those branches.
> > 
> > So on ALL branches?  When did that config option get added?
> 
> It got added in commit 5d6f52671e76 ("ARM: rework endianess selection"),
> released as part of v5.19.
> So only 5.10.y and 5.15.y got broken by "ARM: 9468/1: fix memset64() on
> big-endian".

Ah, ok, that makes more sense.  You can see how I would be confused
given that you asked this to be backported to other newer kernels too
(which is what we should do, just confusion on my side where things were
broken.)

> > > The proposed works always, without requiring kconfig options.
> > > The Fixes: tag target would differ between the stable branches,
> > > so I left it out.
> > 
> > A fixes: for commit 23ea2a4c7232 should be correct, right?
> 
> Somewhat. The original commit 23ea2a4c7232 was not broken, only some of
> its backports. But to keep the stable process happy let's use that.

Fair enough, I'll queue this up for the next round, thanks for the
explaination.

greg k-h