linux-kernel - Re: [RFC PATCH 2/2] treewide, bits: use ffs

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <20260111104002.3e017fe2@pumpkin>
Date: Sun, 11 Jan 2026 10:40:02 +0000
From: David Laight <david.laight.linux@...il.com>
To: "Maciej W. Rozycki" <macro@...am.me.uk>
Cc: Yury Norov <ynorov@...dia.com>, Petr Tesarik <ptesarik@...e.com>, Yury
 Norov <yury.norov@...il.com>, Rasmus Villemoes <linux@...musvillemoes.dk>,
 Richard Henderson <richard.henderson@...aro.org>, Matt Turner
 <mattst88@...il.com>, Magnus Lindholm <linmag7@...il.com>, Vineet Gupta
 <vgupta@...nel.org>, Geert Uytterhoeven <geert@...ux-m68k.org>, Thomas
 Bogendoerfer <tsbogend@...ha.franken.de>, Madhavan Srinivasan
 <maddy@...ux.ibm.com>, Michael Ellerman <mpe@...erman.id.au>, Heiko
 Carstens <hca@...ux.ibm.com>, Vasily Gorbik <gor@...ux.ibm.com>, Alexander
 Gordeev <agordeev@...ux.ibm.com>, Chris Zankel <chris@...kel.net>, Max
 Filippov <jcmvbkbc@...il.com>, Patrik Jakobsson
 <patrik.r.jakobsson@...il.com>, Maarten Lankhorst
 <maarten.lankhorst@...ux.intel.com>, Maxime Ripard <mripard@...nel.org>,
 Thomas Zimmermann <tzimmermann@...e.de>, David Airlie <airlied@...il.com>,
 Simona Vetter <simona@...ll.ch>, Robin Murphy <robin.murphy@....com>, Joerg
 Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>, Jakub Kicinski
 <kuba@...nel.org>, Andrew Lunn <andrew+netdev@...n.ch>, "David S. Miller"
 <davem@...emloft.net>, Eric Dumazet <edumazet@...gle.com>, Paolo Abeni
 <pabeni@...hat.com>, Oliver Neukum <oliver@...kum.org>, Arnd Bergmann
 <arnd@...db.de>, Kuan-Wei Chiu <visitorckw@...il.com>, Andrew Morton
 <akpm@...ux-foundation.org>, Marcel Holtmann <marcel@...tmann.org>, Johan
 Hedberg <johan.hedberg@...il.com>, Luiz Augusto von Dentz
 <luiz.dentz@...il.com>, Pablo Neira Ayuso <pablo@...filter.org>, Florian
 Westphal <fw@...len.de>, linux-kernel@...r.kernel.org
Subject: Re: [RFC PATCH 2/2] treewide, bits: use ffs_val() where it is
 open-coded

On Sun, 11 Jan 2026 03:15:22 +0000 (GMT)
"Maciej W. Rozycki" <macro@...am.me.uk> wrote:

> On Sat, 10 Jan 2026, David Laight wrote:
> 
> > > > > diff --git a/arch/mips/dec/ecc-berr.c b/arch/mips/dec/ecc-berr.c
> > > > > index 1eb356fdd8323..8934b8b1cf375 100644
> > > > > --- a/arch/mips/dec/ecc-berr.c
> > > > > +++ b/arch/mips/dec/ecc-berr.c
> > > > > @@ -153,7 +153,7 @@ static int dec_ecc_be_backend(struct pt_regs *regs, int is_fixup, int invoker)
> > > > >  			/* Ack now, now we've rewritten (or not). */
> > > > >  			dec_ecc_be_ack();
> > > > >  
> > > > > -			if (syn && syn == (syn & -syn)) {
> > > > > +			if (syn && syn == ffs_val(syn)) {    
> > > > 
> > > > It opencodes is_power_of_2().  
> > 
> > Badly...  
> 
>  It's 4 MIPS instructions and exactly the same machine code produced as 
> compiler output from `is_power_of_2'.

The compiler must be detecting that x == (x & -x) is the same as
(x & (x - 1)) == 0.
Although for MIPS the former is negate, and, beq(x,y) - so 3 instructions.
On x86 it is negate, and, cmp, beq(zero flag) - one extra instruction.
(The 4th MIPS instruction will be beq(syn,0).)

So maybe s/Badly/In an unusual way/

> If you know of a better alternative

Doing is_power_of_2() with only one conditional branch would be a gain.
But I've not thought about it hard enough to find one.
I suspect there may not be one, but all these 'tricks' come from the 1970s
(or earlier) and don't allow for the behaviour of modern cpu with multiple
execution units and long pipelines.
(Although MIPS is likely to be relatively sane.)

	David

> I'll be happy to get enlightened, however it's academic anyway, as it's 
> the ECC memory error handler.  If you get here, then you have a bigger 
> issue than a couple of extra instructions executed per kernel log entry 
> produced.  If you indeed can get rid of them in the first place, that is.
> 
>   Maciej
>