Re: [PATCH v5 1/3] x86/process: Shorten the default LAM tag width

[David Laight <david.laight.linux@gmail.com>]

On Tue, 07 Apr 2026 21:53:32 +0000
Maciej Wieczor-Retman <m.wieczorretman@pm.me> 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 <m.wieczorretman@pm.me> wrote:
> >  
> >> From: Maciej Wieczor-Retman <maciej.wieczor-retman@intel.com>
> >>
> >> 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 <maciej.wieczor-retman@intel.com>
> >> ---
> >> 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().

> 
> >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

> 
> >If this had been done for 48bit vaddr, you would really have wished that
> >that bits 62-59 had been used not 51-48.
> >
> >	David
> >  
>