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

[Maciej Wieczor-Retman]

On 2026-03-06 at 18:58:31 +0200, Nikolay Borisov wrote:
>
>
>On 2.03.26 г. 17:34 ч., Maciej Wieczor-Retman 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 default lam to
>> 4 bits as ChkTag will likely be the main user of the interface and such
>> connection should simplify things in the future.
>>
>> Signed-off-by: Maciej Wieczor-Retman <maciej.wieczor-retman@xxxxxxxxx>
>> ---
>> 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
>
>If this is getting standartized across architectures shouldn't there be
>some shared header file which contains arch-agnostic definitions, which
>could then be used by the arch-specific code?

I think this patchset should mostly just clarify the intentions, make
specifically x86's LAM 4-bit so any users that might appear in the near future
are used to this width and not the bigger one.

On across arch level I'd say right now it's about x86 preparing ground to have
some common features of address masking with other architectures that seem to
follow the 4-bit width notion.

For now I recall only MTE using 4-bit tags in cooperation with TBI but I'm not
yet sure if it has any value to take the tag width out of arch code for these
two use cases. I'm working on a KASAN series for x86 in parallel for some time
and maybe if/once that's merged it would make sense to generalize some
constants/functions.

-- 
Kind regards
Maciej Wieczór-Retman