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

[Maciej Wieczor-Retman]

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@xxxxx> wrote:
>
>> From: Maciej Wieczor-Retman <maciej.wieczor-retman@xxxxxxxxx>
>>
>> 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@xxxxxxxxx>
>> ---
>> 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 bee na GENMASK() instead. Is there a downside to using GENMASK() here?

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

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

-- 
Kind regards
Maciej Wieczór-Retman