On 2026-04-08 at 09:51:44 +0100, David Laight wrote:
>On Tue, 07 Apr 2026 21:53:32 +0000
>Maciej Wieczor-Retman <[email protected]> wrote:
>
>> On 2026-04-07 at 22:36:53 +0100, David Laight wrote:
>> >On Tue, 07 Apr 2026 17:45:20 +0000
>> >Maciej Wieczor-Retman <[email protected]> wrote:
>> >
>> >> From: Maciej Wieczor-Retman <[email protected]>
>> >>
>> >> With the announcement of ChkTag, it's worth preparing a stable x86
>> >> linear address masking (lam) user interface. One important aspect of lam
>> >> is the tag width, and aligning it with other industry solutions can
>> >> provide a more popular, generalized interface that other technologies
>> >> could utilize.
>> >>
>> >> ChkTag will use 4-bit tags and since that's the direction other memory
>> >> tagging implementations seem to be taking too (for example Arm's MTE)
>> >> it's reasonable to converge lam in linux to the same specification. Even
>> >> though x86's LAM supports 6-bit tags it is beneficial to shorten lam to
>> >> 4 bits as ChkTag will likely be the main user of the interface and such
>> >> connection should simplify things in the future.
>> >>
>> >> Shrink the maximum acceptable tag width from 6 to 4.
>> >>
>> >> Signed-off-by: Maciej Wieczor-Retman <[email protected]>
>> >> ---
>> >> Changelog v4:
>> >> - Ditch the default wording in the patch message.
>> >> - Add the imperative last line as Dave suggested.
>> >>
>> >> Changelog v3:
>> >> - Remove the variability of the lam width after the debugfs part was
>> >> removed from the patchset.
>> >>
>> >> arch/x86/kernel/process_64.c | 8 ++++----
>> >> 1 file changed, 4 insertions(+), 4 deletions(-)
>> >>
>> >> diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
>> >> index 08e72f429870..1a0e96835bbc 100644
>> >> --- a/arch/x86/kernel/process_64.c
>> >> +++ b/arch/x86/kernel/process_64.c
>> >> @@ -797,7 +797,7 @@ static long prctl_map_vdso(const struct vdso_image
>> >> *image, unsigned long addr)
>> >>
>> >> #ifdef CONFIG_ADDRESS_MASKING
>> >>
>> >> -#define LAM_U57_BITS 6
>> >> +#define LAM_DEFAULT_BITS 4
>> >>
>> >> static void enable_lam_func(void *__mm)
>> >> {
>> >> @@ -814,7 +814,7 @@ static void enable_lam_func(void *__mm)
>> >> static void mm_enable_lam(struct mm_struct *mm)
>> >> {
>> >> mm->context.lam_cr3_mask = X86_CR3_LAM_U57;
>> >> - mm->context.untag_mask = ~GENMASK(62, 57);
>> >> + mm->context.untag_mask = ~GENMASK(57 + LAM_DEFAULT_BITS - 1, 57);
>> >
>> >I'm not sure that GENMASK() is really the best way to describe that value.
>> >It really is ((1ul << LAM_BITS) - 1) << 57 and even the 57 shouldn't be
>> >a magic constant.
>>
>> I recall people were annoyed when I previously open coded something that
>> could
>> have been a GENMASK() instead. Is there a downside to using GENMASK() here?
>
>Some people do like GENMASK(), personally I don't think it helps in many cases.
>Fine if you are describing a hardware register that has some single bit
>fields and some multi-bit fields - especially if the documentation uses
>bit numbers (which is often true).
>But here you want something that has a base bit number (57) and a width
>(LAM_BITS) and that isn't GENMASK().
Would GENMASK() be okay if I put a define on the bit numbers?
#define LAM_LS_BIT 57
#define LAM_MS_BIT LAM_LS_BIT + LAM_DEFAULT_BITS - 1 /* 60 */
...
mm->context.untag_mask = ~GENMASK(LAM_MS_BIT, LAM_LS_BIT);
LS/MS as in least/most significant bit.
>>
>> >I also wonder how userspace knows which bits to use. The other patches
>> >just seem to handle a count from userspace, but you aren't giving out
>> >the highest available bits.
>>
>> I'd imagine if someone was writing a userspace program that'd interface with
>> LAM
>> they'd have to know which bits are okay to use.
>>
>> But maybe I'm misunderstanding what you meant.
>
>That is exactly what I meant, how do they find out which bits to use.
>The API seems so let them say how many they want, but not which ones.
>
> David
Oh then the arch_prctl() call for ARCH_GET_UNTAG_MASK is what they'd want to
use. It returns the untag_mask.
--
Kind regards
Maciej Wieczór-Retman
