On 2026-04-07 at 22:36:53 +0100, David Laight wrote: >On Tue, 07 Apr 2026 17:45:20 +0000 >Maciej Wieczor-Retman <[email protected]> wrote: > >> From: Maciej Wieczor-Retman <[email protected]> >> >> 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 <[email protected]> >> --- >> 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
