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