[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20260208114214.270b4982@pumpkin>
Date: Sun, 8 Feb 2026 11:42:14 +0000
From: David Laight <david.laight.linux@...il.com>
To: Yury Norov <ynorov@...dia.com>
Cc: Nathan Chancellor <nathan@...nel.org>, Greg Kroah-Hartman
<gregkh@...uxfoundation.org>, Thomas Gleixner <tglx@...utronix.de>, Peter
Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...nel.org>, Mathieu
Desnoyers <mathieu.desnoyers@...icios.com>, Arnd Bergmann <arnd@...db.de>,
linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org, Yury Norov
<yury.norov@...il.com>, Lucas De Marchi <lucas.demarchi@...el.com>, Jani
Nikula <jani.nikula@...el.com>, Vincent Mailhol
<mailhol.vincent@...adoo.fr>, Andy Shevchenko
<andriy.shevchenko@...ux.intel.com>, Kees Cook <keescook@...omium.org>,
Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH next 10/14] bits: Fix assmebler expansions of
GENMASK_Uxx() and BIT_Uxx()
On Sat, 7 Feb 2026 22:31:34 -0500
Yury Norov <ynorov@...dia.com> wrote:
> On Wed, Jan 21, 2026 at 02:57:27PM +0000, david.laight.linux@...il.com wrote:
> > From: David Laight <david.laight.linux@...il.com>
> >
> > The assembler only supports one type of signed integers, so expressions
> > using BITS_PER_LONG (etc) cannot be guaranteed to be correct.
> >
> > Use ((2 << (h)) - (1 << (l))) for all assembler GENMASK() expansions and
> > add definitions of BIT_Uxx() as (1 << (nr)).
> >
> > Note that 64bit results are (probably) only correct for 64bit builds
> > and 128bits results will never be valid.
>
> And this important note will sink in git history.
At least it isn't only in the email archives.
I can put it in a comment.
> > Signed-off-by: David Laight <david.laight.linux@...il.com>
>
> This has been discussed in details when those GENMASK_Uxx() were
> introduced. Assembler doesn't support C types, and can't provide any
> guarantees. It may only confuse readers when they see something like
> GENMASK_U8() in the assembler code, and there's nothing on behalf of
> that declaration to enforce the limitation.
It won't be in asm code, the asm code will be expanding a constant
from a C header file.
> That's why we didn't add fake C types support in the assembler. Unless
> we find a way to enforce C types capacity in assembler(s), let's keep
> those macros C-only.
But GENMASK_ULL() was already there and would generate invalid values
(for small values) on 32bit.
The only reason for defining these for assembler is so that .h files
that use the definitions can be used in .S files.
As soon as any of the BIT_Unn() get used the asm code is likely to
try to expand them.
David
>
> Thanks,
> Yury
Powered by blists - more mailing lists