| 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
| ||
|
Message-ID: <aQCJuADNYTzdbPQJ@smile.fi.intel.com>
Date: Tue, 28 Oct 2025 11:15:36 +0200
From: Andy Shevchenko <andriy.shevchenko@...el.com>
To: Geert Uytterhoeven <geert+renesas@...der.be>
Cc: Michael Turquette <mturquette@...libre.com>,
Stephen Boyd <sboyd@...nel.org>,
Nicolas Ferre <nicolas.ferre@...rochip.com>,
Alexandre Belloni <alexandre.belloni@...tlin.com>,
Claudiu Beznea <claudiu.beznea@...on.dev>,
Giovanni Cabiddu <giovanni.cabiddu@...el.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
David Miller <davem@...emloft.net>,
Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>, Joel Stanley <joel@....id.au>,
Andrew Jeffery <andrew@...econstruct.com.au>,
Crt Mori <cmo@...exis.com>, Jonathan Cameron <jic23@...nel.org>,
Lars-Peter Clausen <lars@...afoo.de>,
Jacky Huang <ychuang3@...oton.com>,
Shan-Chun Hung <schung@...oton.com>,
Yury Norov <yury.norov@...il.com>,
Rasmus Villemoes <linux@...musvillemoes.dk>,
Jaroslav Kysela <perex@...ex.cz>, Takashi Iwai <tiwai@...e.com>,
Johannes Berg <johannes@...solutions.net>,
Jakub Kicinski <kuba@...nel.org>, Alex Elder <elder@...e.org>,
David Laight <david.laight.linux@...il.com>,
Vincent Mailhol <mailhol.vincent@...adoo.fr>,
Jason Baron <jbaron@...mai.com>, Borislav Petkov <bp@...en8.de>,
Tony Luck <tony.luck@...el.com>,
Michael Hennerich <Michael.Hennerich@...log.com>,
Kim Seer Paller <kimseer.paller@...log.com>,
David Lechner <dlechner@...libre.com>,
Nuno Sá <nuno.sa@...log.com>,
Andy Shevchenko <andy@...nel.org>,
Richard Genoud <richard.genoud@...tlin.com>,
Cosmin Tanislav <demonsingur@...il.com>,
Biju Das <biju.das.jz@...renesas.com>,
Jianping Shen <Jianping.Shen@...bosch.com>,
linux-clk@...r.kernel.org, linux-arm-kernel@...ts.infradead.org,
linux-renesas-soc@...r.kernel.org, linux-crypto@...r.kernel.org,
linux-edac@...r.kernel.org, qat-linux@...el.com,
linux-gpio@...r.kernel.org, linux-aspeed@...ts.ozlabs.org,
linux-iio@...r.kernel.org, linux-sound@...r.kernel.org,
linux-kernel@...r.kernel.org,
Jonathan Cameron <Jonathan.Cameron@...wei.com>
Subject: Re: [PATCH v5 11/23] bitfield: Add non-constant field_{prep,get}()
helpers
On Mon, Oct 27, 2025 at 07:41:45PM +0100, Geert Uytterhoeven wrote:
> The existing FIELD_{GET,PREP}() macros are limited to compile-time
> constants. However, it is very common to prepare or extract bitfield
> elements where the bitfield mask is not a compile-time constant.
>
> To avoid this limitation, the AT91 clock driver and several other
> drivers already have their own non-const field_{prep,get}() macros.
> Make them available for general use by adding them to
> <linux/bitfield.h>, and improve them slightly:
> 1. Avoid evaluating macro parameters more than once,
> 2. Replace "ffs() - 1" by "__ffs()",
> 3. Support 64-bit use on 32-bit architectures,
> 4. Wire field_{get,prep}() to FIELD_{GET,PREP}() when mask is
> actually constant.
>
> This is deliberately not merged into the existing FIELD_{GET,PREP}()
> macros, as people expressed the desire to keep stricter variants for
> increased safety, or for performance critical paths.
Some comments below, but FWIW,
Reviewed-by: Andy Shevchenko <andriy.shevchenko@...el.com>
after addressing them.
...
> +#define __field_prep(mask, val) \
> + ({ \
> + __auto_type __mask = (mask); \
> + typeof(mask) __val = (val); \
> + unsigned int __shift = BITS_PER_TYPE(mask) <= 32 ? \
> + __ffs(__mask) : __ffs64(__mask); \
> + (__val << __shift) & __mask; \
Unaligned \
> + })
> +
> +#define __field_get(mask, reg) \
> + ({ \
> + __auto_type __mask = (mask); \
> + typeof(mask) __reg = (reg); \
> + unsigned int __shift = BITS_PER_TYPE(mask) <= 32 ? \
> + __ffs(__mask) : __ffs64(__mask); \
> + (__reg & __mask) >> __shift; \
Ditto.
> + })
> +/**
> + * field_prep() - prepare a bitfield element
> + * @mask: shifted mask defining the field's length and position, must be
> + * non-zero
> + * @val: value to put in the field
> + *
> + * field_prep() masks and shifts up the value. The result should be
> + * combined with other fields of the bitfield using logical OR.
> + * Unlike FIELD_PREP(), @mask is not limited to a compile-time constant.
> + * Typical usage patterns are a value stored in a table, or calculated by
> + * shifting a constant by a variable number of bits.
> + * If you want to ensure that @mask is a compile-time constant, please use
> + * FIELD_PREP() directly instead.
Shouldn't it have Return section as well?
> + */
> +#define field_prep(mask, val) \
> + (__builtin_constant_p(mask) ? FIELD_PREP(mask, val) \
> + : __field_prep(mask, val))
Personally I would give it a single line (but it's up to you, folks).
> +
> +/**
> + * field_get() - extract a bitfield element
> + * @mask: shifted mask defining the field's length and position, must be
> + * non-zero
> + * @reg: value of entire bitfield
> + *
> + * field_get() extracts the field specified by @mask from the
> + * bitfield passed in as @reg by masking and shifting it down.
> + * Unlike FIELD_GET(), @mask is not limited to a compile-time constant.
> + * Typical usage patterns are a value stored in a table, or calculated by
> + * shifting a constant by a variable number of bits.
> + * If you want to ensure that @mask is a compile-time constant, please use
> + * FIELD_GET() directly instead.
Ditto.
> + */
> +#define field_get(mask, reg) \
> + (__builtin_constant_p(mask) ? FIELD_GET(mask, reg) \
> + : __field_get(mask, reg))
As per above.
--
With Best Regards,
Andy Shevchenko
Powered by blists - more mailing lists