linux-kernel - Re: [PATCH v4 00/13] Introduce parity_odd() and refactor redundant parity code

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

Message-ID: <aAyj9SMvYrN9tXZC@visitorckw-System-Product-Name>
Date: Sat, 26 Apr 2025 17:14:29 +0800
From: Kuan-Wei Chiu <visitorckw@...il.com>
To: "H. Peter Anvin" <hpa@...or.com>, Yury Norov <yury.norov@...il.com>
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,
	jirislaby@...nel.org, akpm@...ux-foundation.org, jdelvare@...e.com,
	linux@...ck-us.net, alexandre.belloni@...tlin.com, pgaj@...ence.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, Frank.Li@....com,
	linux-hwmon@...r.kernel.org, linux-i3c@...ts.infradead.org,
	david.laight.linux@...il.com, andrew.cooper3@...rix.com,
	Yu-Chun Lin <eleanor15x@...il.com>
Subject: Re: [PATCH v4 00/13] Introduce parity_odd() and refactor redundant
 parity code

On Fri, Apr 25, 2025 at 12:33:21PM -0700, H. Peter Anvin wrote:
> On 4/11/25 09:34, Kuan-Wei Chiu wrote:
> > > 
> > > In either case, instead of packing the cascade into one function, make good
> > > use of it.
> > > 
> > > In the latter case, __builtin_constant_p() isn't necessary as it puts the
> > > onus on the architecture to separate out const and non-const cases, if it
> > > matters -- which it doesn't if the architecture simply wants to use
> > > __builtin_parity:
> > > 
> > > #define parity8(x)  ((bool) __builtin_parity((u8)(x)))
> > > #define parity16(x) ((bool) __builtin_parity((u16)(x)))
> > > #define parity32(x) ((bool) __builtin_parity((u32)(x)))
> > > #define parity64(x) ((bool) __builtin_parityll((u64)(x)))
> > > 
> > > As stated before, I don't really see that the parity function itself would
> > > be very suitable for a generic helper, but if it were to, then using the
> > > "standard" macro construct for it would seem to be the better option.
> > > 
> > > (And I would be very much in favor of not open-coding the helper everywhere
> > > but to macroize it; effectively creating a C++ template equivalent. It is
> > > out of scope for this project, though.)
> > > 
> > IIUC, you prefer using the parity8/16/32/64() interface with
> > __builtin_parity(), regardless of whether there are users on the hot
> > path?
> 
> As a per-architecture opt-in, yes.
> 
I'd prefer to see Yury agree first, otherwise there's a high risk of a
maintainer NAK after the next submission.

Regards,
Kuan-Wei