linux-kernel - Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

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 for Android: free password hash cracker in your pocket

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

Message-ID: <eec0dfd7-5e4f-4a08-928c-b7714dbc4a17@zytor.com>
Date: Tue, 25 Mar 2025 12:43:25 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Kuan-Wei Chiu <visitorckw@...il.com>, Yury Norov <yury.norov@...il.com>
Cc: David Laight <david.laight.linux@...il.com>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Laurent.pinchart@...asonboard.com, airlied@...il.com,
        akpm@...ux-foundation.org, alistair@...ple.id.au,
        andrew+netdev@...n.ch, andrzej.hajda@...el.com,
        arend.vanspriel@...adcom.com, awalls@...metrocast.net, bp@...en8.de,
        bpf@...r.kernel.org, brcm80211-dev-list.pdl@...adcom.com,
        brcm80211@...ts.linux.dev, dave.hansen@...ux.intel.com,
        davem@...emloft.net, dmitry.torokhov@...il.com,
        dri-devel@...ts.freedesktop.org, eajames@...ux.ibm.com,
        edumazet@...gle.com, eleanor15x@...il.com, gregkh@...uxfoundation.org,
        hverkuil@...all.nl, jernej.skrabec@...il.com, jirislaby@...nel.org,
        jk@...abs.org, joel@....id.au, johannes@...solutions.net,
        jonas@...boo.se, jserv@...s.ncku.edu.tw, kuba@...nel.org,
        linux-fsi@...ts.ozlabs.org, linux-input@...r.kernel.org,
        linux-kernel@...r.kernel.org, linux-media@...r.kernel.org,
        linux-mtd@...ts.infradead.org, linux-serial@...r.kernel.org,
        linux-wireless@...r.kernel.org, linux@...musvillemoes.dk,
        louis.peens@...igine.com, maarten.lankhorst@...ux.intel.com,
        mchehab@...nel.org, mingo@...hat.com, miquel.raynal@...tlin.com,
        mripard@...nel.org, neil.armstrong@...aro.org, netdev@...r.kernel.org,
        oss-drivers@...igine.com, pabeni@...hat.com,
        parthiban.veerasooran@...rochip.com, rfoss@...nel.org, richard@....at,
        simona@...ll.ch, tglx@...utronix.de, tzimmermann@...e.de,
        vigneshr@...com, x86@...nel.org
Subject: Re: [PATCH v3 00/16] Introduce and use generic parity16/32/64 helper

On 3/23/25 08:16, Kuan-Wei Chiu wrote:
> 
> Interface 3: Multiple Functions
> Description: bool parity_odd8/16/32/64()
> Pros: No need for explicit casting; easy to integrate
>        architecture-specific optimizations; except for parity8(), all
>        functions are one-liners with no significant code duplication
> Cons: More functions may increase maintenance burden
> Opinions: Only I support this approach
> 

OK, so I responded to this but I can't find my reply or any of the 
followups, so let me go again:

I prefer this option, because:

a. Virtually all uses of parity is done in contexts where the sizes of 
the items for which parity is to be taken are well-defined, but it is 
*really* easy for integer promotion to cause a value to be extended to 
32 bits unnecessarily (sign or zero extend, although for parity it 
doesn't make any difference -- if the compiler realizes it.)

b. It makes it easier to add arch-specific implementations, notably 
using __builtin_parity on architectures where that is known to generate 
good code.

c. For architectures where only *some* parity implementations are 
fast/practical, the generic fallbacks will either naturally synthesize 
them from components via shift-xor, or they can be defined to use a 
larger version; the function prototype acts like a cast.

d. If there is a reason in the future to add a generic version, it is 
really easy to do using the size-specific functions as components; this 
is something we do literally all over the place, using a pattern so 
common that it, itself, probably should be macroized:

#define parity(x) 				\
({						\
	typeof(x) __x = (x);			\
	bool __y;				\
	switch (sizeof(__x)) {			\
		case 1:				\
			__y = parity8(__x);	\
			break;			\
		case 2:				\
			__y = parity16(__x);	\
			break;			\
		case 4:				\
			__y = parity32(__x);	\
			break;			\
		case 8:				\
			__y = parity64(__x);	\
			break;			\
		default:			\
			BUILD_BUG();		\
			break;			\
	}					\
	__y;					\
})