public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Maciej Wieczor-Retman <m.wieczorretman@pm.me>
To: peterz@infradead.org, ryan.roberts@arm.com,
	ilpo.jarvinen@linux.intel.com, maciej.wieczor-retman@intel.com,
	jgross@suse.com, morbo@google.com, mingo@redhat.com,
	ljs@kernel.org, nathan@kernel.org, shuah@kernel.org,
	akpm@linux-foundation.org, james.morse@arm.com, oleg@redhat.com,
	houwenlong.hwl@antgroup.com, xin@zytor.com,
	justinstitt@google.com, seanjc@google.com, hpa@zytor.com,
	perry.yuan@amd.com, bp@alien8.de, dave.hansen@linux.intel.com,
	sohil.mehta@intel.com, tglx@kernel.org,
	nick.desaulniers+lkml@gmail.com
Cc: linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	llvm@lists.linux.dev, x86@kernel.org, m.wieczorretman@pm.me
Subject: [PATCH v6 0/3] x86: Simplifying LAM
Date: Fri, 10 Apr 2026 09:55:17 +0000	[thread overview]
Message-ID: <cover.1775813245.git.m.wieczorretman@pm.me> (raw)

After ChkTag [1] announcement, 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
long run.

If a usecase arises in the future, the 6-bit tags can be made available as a
debug feature and possible to enable through debugfs.

Changing the tag width at the moment has no effect on userspace programs. Due to
LAM being disabled until LASS is fully supported in the kernel there are yet no
userspace projects relying on a specific LAM tag width. One known exception is
the clang compiler and its hwasan support. It is however not a problem since
there are both no users of hwasan on x86 yet and upon closer inspection (when
working on x86 KASAN software tag-based mode) I found it's not working correctly
and needs to be patched.

The patchset also cleans up some comments referencing LAM_U48 which was not
implemented in the kernel and the comments shouldn't imply it can be enabled.

Patches are based on v7.0-rc7

Changelog v6:
- 1/3
	- Change define names so they match the arch_prctl() cases for
	  LAM.
	- Add more defines so they build into the GENMASK() more
	  properly.
- 2/3
	- Add one reviewed-by.
- 3/3
	- Update the patch subject after removing additional test cases
	  during v3.
	- Change bit width and untag mask defines so they match the
	  kernel ones in name and add GENMASK() to x86 selftests so
	  they match the kernel in form. Update the patch description.

Changelog v5:
- Rebase onto v7.0-rc7.

Changelog v4:
- Remove the 'default' wording from the cover letter and patch messages.
- Add a paragraph to the cover letter about userspace impact.

Changelog v3:
- Remove the debugfs part and update the rest of the code and patch
  messages accordingly.

Changelog v2:
- Extend a char buffer in debugfs read callback to fit the format
  string.

[1] https://community.intel.com/t5/Blogs/Tech-Innovation/open-intel/ChkTag-x86-Memory-Safety/post/1721490

Maciej Wieczor-Retman (3):
  x86/process: Shorten the default LAM tag width
  x86/mm: Cleanup comments where LAM_U48 is mentioned
  selftests/lam: Update LAM tag width and cleanup names

 arch/x86/include/asm/mmu.h        |  2 +-
 arch/x86/include/asm/tlbflush.h   |  2 +-
 arch/x86/kernel/process_64.c      | 11 ++--
 tools/testing/selftests/x86/lam.c | 94 ++++++++++++++++---------------
 4 files changed, 58 insertions(+), 51 deletions(-)

-- 
2.53.0



             reply	other threads:[~2026-04-10  9:55 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-10  9:55 Maciej Wieczor-Retman [this message]
2026-04-10  9:55 ` [PATCH v6 1/3] x86/process: Shorten the LAM tag width Maciej Wieczor-Retman
2026-04-10  9:55 ` [PATCH v6 2/3] x86/mm: Cleanup comments where LAM_U48 is mentioned Maciej Wieczor-Retman
2026-04-10  9:55 ` [PATCH v6 3/3] selftests/lam: Update LAM tag width and cleanup names Maciej Wieczor-Retman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1775813245.git.m.wieczorretman@pm.me \
    --to=m.wieczorretman@pm.me \
    --cc=akpm@linux-foundation.org \
    --cc=bp@alien8.de \
    --cc=dave.hansen@linux.intel.com \
    --cc=houwenlong.hwl@antgroup.com \
    --cc=hpa@zytor.com \
    --cc=ilpo.jarvinen@linux.intel.com \
    --cc=james.morse@arm.com \
    --cc=jgross@suse.com \
    --cc=justinstitt@google.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=ljs@kernel.org \
    --cc=llvm@lists.linux.dev \
    --cc=maciej.wieczor-retman@intel.com \
    --cc=mingo@redhat.com \
    --cc=morbo@google.com \
    --cc=nathan@kernel.org \
    --cc=nick.desaulniers+lkml@gmail.com \
    --cc=oleg@redhat.com \
    --cc=perry.yuan@amd.com \
    --cc=peterz@infradead.org \
    --cc=ryan.roberts@arm.com \
    --cc=seanjc@google.com \
    --cc=shuah@kernel.org \
    --cc=sohil.mehta@intel.com \
    --cc=tglx@kernel.org \
    --cc=x86@kernel.org \
    --cc=xin@zytor.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox