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

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