linux-kernel - Re: [PATCH 02/17] bitops: Add generic parity calculation for u64

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: <Z79WkNp6p06fV/f9@visitorckw-System-Product-Name>
Date: Thu, 27 Feb 2025 01:59:44 +0800
From: Kuan-Wei Chiu <visitorckw@...il.com>
To: Jiri Slaby <jirislaby@...nel.org>
Cc: Yury Norov <yury.norov@...il.com>, tglx@...utronix.de, mingo@...hat.com,
	bp@...en8.de, dave.hansen@...ux.intel.com, x86@...nel.org,
	jk@...abs.org, joel@....id.au, eajames@...ux.ibm.com,
	andrzej.hajda@...el.com, neil.armstrong@...aro.org,
	rfoss@...nel.org, maarten.lankhorst@...ux.intel.com,
	mripard@...nel.org, tzimmermann@...e.de, airlied@...il.com,
	simona@...ll.ch, dmitry.torokhov@...il.com, mchehab@...nel.org,
	awalls@...metrocast.net, hverkuil@...all.nl,
	miquel.raynal@...tlin.com, richard@....at, vigneshr@...com,
	louis.peens@...igine.com, andrew+netdev@...n.ch,
	davem@...emloft.net, edumazet@...gle.com, pabeni@...hat.com,
	parthiban.veerasooran@...rochip.com, arend.vanspriel@...adcom.com,
	johannes@...solutions.net, gregkh@...uxfoundation.org,
	akpm@...ux-foundation.org, hpa@...or.com, alistair@...ple.id.au,
	linux@...musvillemoes.dk, Laurent.pinchart@...asonboard.com,
	jonas@...boo.se, jernej.skrabec@...il.com, kuba@...nel.org,
	linux-kernel@...r.kernel.org, linux-fsi@...ts.ozlabs.org,
	dri-devel@...ts.freedesktop.org, linux-input@...r.kernel.org,
	linux-media@...r.kernel.org, linux-mtd@...ts.infradead.org,
	oss-drivers@...igine.com, netdev@...r.kernel.org,
	linux-wireless@...r.kernel.org, brcm80211@...ts.linux.dev,
	brcm80211-dev-list.pdl@...adcom.com, linux-serial@...r.kernel.org,
	bpf@...r.kernel.org, jserv@...s.ncku.edu.tw,
	Yu-Chun Lin <eleanor15x@...il.com>
Subject: Re: [PATCH 02/17] bitops: Add generic parity calculation for u64

Hi Jiri,

On Wed, Feb 26, 2025 at 08:14:14AM +0100, Jiri Slaby wrote:
> On 25. 02. 25, 14:29, Kuan-Wei Chiu wrote:
> > > +#define parity(val)					\
> > > +({							\
> > > +	u64 __v = (val);				\
> > > +	int __ret;					\
> > > +	switch (BITS_PER_TYPE(val)) {			\
> > > +	case 64:					\
> > > +		__v ^= __v >> 32;			\
> > > +		fallthrough;				\
> > > +	case 32:					\
> > > +		__v ^= __v >> 16;			\
> > > +		fallthrough;				\
> > > +	case 16:					\
> > > +		__v ^= __v >> 8;			\
> > > +		fallthrough;				\
> > > +	case 8:						\
> > > +		__v ^= __v >> 4;			\
> > > +		__ret =  (0x6996 >> (__v & 0xf)) & 1;	\
> > > +		break;					\
> > > +	default:					\
> > > +		BUILD_BUG();				\
> > > +	}						\
> > > +	__ret;						\
> > > +})
> > > +
> > > +#define parity8(val)	parity((u8)(val))
> > > +#define parity32(val)	parity((u32)(val))
> > > +#define parity64(val)	parity((u64)(val))
> > What do you think about using these inline functions instead of macros?
> > Except for parity8(), each function is a single line and follows the
> > same logic. I find inline functions more readable, and coding-style.rst
> > also recommends them over macros.
> 
> Not in cases where macros are inevitable. I mean, do we need parityXX() for
> XX in (8, 16, 32, 64) at all? Isn't the parity() above enough for everybody?
> And if not, you can have all those parityXX() as inlines as you suggest, but
> also provide a macro such as the above to call (optimized) parityXX() as per
> datatype len.
> 
I agree that we can add a macro to call parity8/16/32/64 based on the
data type size. However, I think we should still keep parity8/16/32/64.
As Peter and David discussed, the x86-specific implementations of
parity8() and parity16() might use different instructions instead of
just XORing and calling another function, as in the generic version.

My current idea is to follow David's suggestion and use
__builtin_parity when there is no architecture-specific implementation.
In lib/, we can provide a generic weak function implementation of
__parity[sdt]i2.

Any comments or suggestions are welcome!

Regards,
Kuan-Wei

static inline parity32(u32 val)
{
    return __builtin_const_p(val) ? _parity_const(val) : _parity32(val);
}

#ifndef _parity32
static inline _parity32(u32 val)
{
    return __builtin_parity(val);
}
#endif

int __weak __paritysi2(u32 val);
int __weak __paritysi2(u32 val)
{
    val ^= val >> 16;
    val ^= val >> 8;
    val ^= val >> 4;
    return (0x6996 >> (val & 0xf)) & 1;
}
EXPORT_SYMBOL(__paritysi2);