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

["Edgecombe, Rick P" <rick.p.edgecombe@intel.com>]

On Fri, 2026-04-10 at 09:55 +0000, Maciej Wieczor-Retman wrote:
>  
>  #ifdef CONFIG_ADDRESS_MASKING
>  
> -#define LAM_U57_BITS 6
> +#define LAM_TAG_BITS	4
> +#define LAM_LS_BIT	57
> +#define LAM_MS_BIT	(LAM_LS_BIT + LAM_TAG_BITS - 1) /* 60 */
> +#define LAM_UNTAG_MASK	~GENMASK(LAM_MS_BIT, LAM_LS_BIT)
>  
>  static void enable_lam_func(void *__mm)
>  {
> @@ -814,7 +817,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 = LAM_UNTAG_MASK;
>  

It's been a bit since I looked at LAM. The untag_mask is used to strip the
addresses passed by userspace, right? So this lies to userspace about the
tagging behavior of the CPU? Userspace still gets the LAM_U57 behavior, but is
told the untag mask is the 4 chcktag bits?

If so, then there will be a difference between userspace accesses to a pointer
and the kernel's handling of a user pointer (mmap(), gup, etc). I don't know
that it is unsafe, but have you thought through the implications? Besides that
though it's a weird ABI.

What is the chktag behavior for bits 61 and 62? Are they ignored or trigger a
#GP?

>  	/*
>  	 * Even though the process must still be single-threaded at this
> @@ -850,7 +853,7 @@ static int prctl_enable_tagged_addr(struct mm_struct *mm, unsigned long nr_bits)
>  		return -EBUSY;
>  	}
>  
> -	if (!nr_bits || nr_bits > LAM_U57_BITS) {
> +	if (!nr_bits || nr_bits > LAM_TAG_BITS) {
>  		mmap_write_unlock(mm);