On Tue, 07 Apr 2026 21:53:32 +0000 Maciej Wieczor-Retman <[email protected]> wrote:
> 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 been a GENMASK() instead. Is there a downside to using GENMASK() here? Some people do like GENMASK(), personally I don't think it helps in many cases. Fine if you are describing a hardware register that has some single bit fields and some multi-bit fields - especially if the documentation uses bit numbers (which is often true). But here you want something that has a base bit number (57) and a width (LAM_BITS) and that isn't GENMASK(). > > >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. That is exactly what I meant, how do they find out which bits to use. The API seems so let them say how many they want, but not which ones. David > > >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 > > >
