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

Message-ID: <8571fd6f-4e71-4a6d-b2e8-16d9d72fa56e@zytor.com>
Date: Fri, 25 Apr 2025 12:33:21 -0700
From: "H. Peter Anvin" <hpa@...or.com>
To: Kuan-Wei Chiu <visitorckw@...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 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.

	-hpa