[PATCH 2/2] malloc: change tunable glibc.mem.tagging to glibc.mem.aarch64_mte
Sunil Pandey
skpgkp2@gmail.com
Thu Mar 26 17:22:36 GMT 2026
On Thu, Mar 26, 2026 at 2:32 AM Yury Khrustalev <yury.khrustalev@arm.com>
wrote:
> On Wed, Mar 25, 2026 at 12:38:01PM -0700, Sunil Pandey wrote:
> > On Wed, Mar 25, 2026 at 11:15 AM Adhemerval Zanella Netto <
> > adhemerval.zanella@linaro.org> wrote:
> >
> > >
> > >
> > > On 25/03/26 14:50, Sunil Pandey wrote:
> > > >
> > > >
> > > > On Wed, Mar 25, 2026 at 10:28 AM Adhemerval Zanella Netto <
> > > adhemerval.zanella@linaro.org <mailto:adhemerval.zanella@linaro.org>>
> > > wrote:
> > >
> > > > > diff --git a/manual/tunables.texi b/manual/tunables.texi
> > > > > index 72769428e8..772148b2fa 100644
> > > > > --- a/manual/tunables.texi
> > > > > +++ b/manual/tunables.texi
> > > > > @@ -40,7 +40,6 @@ glibc.malloc.perturb: 0 (min: 0, max: 255)
> > > > > glibc.cpu.x86_shared_cache_size: 0x100000 (min: 0x0, max:
> > > 0xffffffffffffffff)
> > > > > glibc.pthread.rseq: 1 (min: 0, max: 1)
> > > > > glibc.cpu.prefer_map_32bit_exec: 0 (min: 0, max: 1)
> > > > > -glibc.mem.tagging: 0 (min: 0, max: 255)
> > > > > glibc.malloc.hugetlb: 0x0 (min: 0x0, max: 0xffffffffffffffff)
> > > > > glibc.cpu.x86_rep_movsb_threshold: 0x2000 (min: 0x100, max:
> > > 0xffffffffffffffff)
> > > > > glibc.malloc.mxfast: 0x0 (min: 0x0, max: 0xffffffffffffffff)
> > > > > @@ -663,32 +662,21 @@ This tunable namespace supports
> operations
> > > that affect the way @theglibc{}
> > > > > and the process manage memory.
> > > > > @end deftp
> > > > >
> > > > > -@deftp Tunable glibc.mem.tagging
> > > > > -If the hardware supports memory tagging, this tunable can be
> used
> > > to
> > > > > -control the way @theglibc{} uses this feature. At present
> this
> > > is only
> > > > > -supported on AArch64 systems with the MTE extension; it is
> > > ignored for
> > > > > -all other systems.
> > > > > +@deftp Tunable glibc.mem.aarch64_mte
> > > > > +On AArch64 systems that support the Memory Tagging Extension
> > > (MTE) extension
> > > > > +this tunable allows to select the tag check fault mode (MTE
> > > mode). This
> > > > > +tunable only has effect when @theglibc{} has been configured
> with
> > > > > +@code{--enable-memory-tagging}.
> > > > >
> > > > > -This tunable takes a value between 0 and 255 and acts as a
> bitmask
> > > > > -that enables various capabilities.
> > > > > +Available values are:
> > > > >
> > > > > -Bit 0 (the least significant bit) causes the @code{malloc}
> > > > > -subsystem to allocate
> > > > > -tagged memory, with each allocation being assigned a random
> tag.
> > > > > -
> > > > > -Bit 1 enables precise faulting mode for tag violations on
> systems
> > > that
> > > > > -support deferred tag violation reporting. This may cause
> programs
> > > > > -to run more slowly.
> > > > > -
> > > > > -Bit 2 enables either precise or deferred faulting mode for tag
> > > violations
> > > > > -whichever is preferred by the system.
> > > > > -
> > > > > -Other bits are currently reserved.
> > > > > -
> > > >
> > > >
> > > > I prefer generic Bit 0, 1 and 2..methods, where each architecture can
> > > define its own meaning
> > > > depending on memory tagging design/feature.
> > > >
> > > > Manuals can be updated in architecture specific ways.
> > > >
> > > > For example:
> > > >
> > > > - Bit 0: subsystem to allocate tagged memory, with each allocation
> being
> > > assigned a random tag.
> > > >
> > > > - Bit 1: In ARM it means precise faulting mode
> > > > - Bit 1: On x86, it could mean some other tagging feature.
> > > > and so on...
> > > >
> > > > It is also extendable, if we need more feature bits in future.
> > >
> > > The patch makes it arch-specific, so x86 or any other architecture can
> > > define
> > > its own semantic. I think it would make sense to keep current generic
> > > glibc.mem.tagging if we have any indication that x86 or RISCV (which
> > > seems the architecture that have similar memory tagging support in
> > > ISA discussion) have similar support like similar faulting mode.
> > >
> > > Do you know how x86 ChkTag ISA support should work wrt faulting mode?
> From
> > > what I read, ChkTag also uses 4-bit tags, but it does not have
> > > hardware-defined modes as MTE and all ChkTag memory access instruction
> > > are inherently synchronous. It does not make much sense in adding a
> > > faulting
> > > mode if hardware does not support it.
> > >
> > >
> > Even though x86 may not support exact faulting mode as ARM but top level
> > build configuration,
> > runtime tunables can be reused by defining architecture specific
> features
> > and keeping
> > external interface generic. i.e.
> >
> > ARM:
> >
> > Bit 0 (the least significant bit) causes the @code{malloc}
> > subsystem to allocate tagged memory, with each allocation being
> > assigned a random tag.
> >
> > Bit 1 enables precise faulting mode for tag violations on systems
> that
> > support deferred tag violation reporting. This may cause programs
> to
> > run more slowly.
> >
> > Bit 2 enables either precise or deferred faulting mode for tag
> > violations whichever is
> > preferred by the system.
> >
> > Other bits are currently reserved.
> >
> > x86:
> >
> > Bit 0 (the least significant bit) causes the @code{malloc}
> > subsystem to allocate tagged memory.
> >
> > Bit 1 Enable fault mode1
> >
> > Bit 2 Enable fault mode2
> >
> > Other bits are currently reserved.
>
> We're going to have aarch64 tunable for memory tagging with
> MTE-specific values. I don't mind keeping the existing generic
> tunable 'glibc.mem.tagging', however it would be ignored on
> aarch64, and I just thought it would be confusing to have it
> since it's not used anywhere else.
>
> Hope this helps,
> Yury
>
>
My concerns are related to changes in architecture independent files.
diff --git a/config.h.in b/config.h.in
index b53731c393..2f51a40de1 100644
--- a/config.h.in
+++ b/config.h.in
@@ -182,8 +182,9 @@
/* Define if inlined system calls are available. */
#undef HAVE_INLINED_SYSCALLS
-/* Define if memory tagging support should be enabled. */
-#undef USE_MTAG
+/* Define if AArch64 memory tagging features should be enabled. */
+#undef USE_AARCH64_MTAG_HEAP
+#undef USE_AARCH64_MTAG_STACK
diff --git a/malloc/arena.c b/malloc/arena.c
index 727d0517c4..876568d720 100644
--- a/malloc/arena.c
+++ b/malloc/arena.c
@@ -252,19 +252,18 @@ __ptmalloc_init (void)
tcache_key_initialize ();
#endif
-#ifdef USE_MTAG
- if ((TUNABLE_GET_FULL (glibc, mem, tagging, int32_t, NULL) & 1) != 0)
+#ifdef USE_AARCH64_MTAG_HEAP
+ if (__libc_mtag_enabled ())
{
- /* If the tunable says that we should be using tagged memory
+ /* If we should be using tagged memory
and that morecore does not support tagged regions, then
disable it. */
if (__MTAG_SBRK_UNTAGGED)
__always_fail_morecore = true;
-
mtag_enabled = true;
mtag_mmap_flags = __MTAG_MMAP_FLAGS;
}
-#endif
+#endif /* USE_AARCH64_MTAG_HEAP */
#if defined SHARED && IS_IN (libc)
/* In case this libc copy is in a non-default namespace, never use
diff --git a/malloc/malloc.c b/malloc/malloc.c
index 6455a1b0e0..0f5bc08d8c 100644
--- a/malloc/malloc.c
+++ b/malloc/malloc.c
@@ -405,13 +405,13 @@ verify (PTRDIFF_MAX <= SIZE_MAX / 2);
tagging is not enabled, it simply returns the original pointer.
*/
-#ifdef USE_MTAG
+#ifdef USE_AARCH64_MTAG_HEAP
static bool mtag_enabled = false;
static int mtag_mmap_flags = 0;
#else
# define mtag_enabled false
# define mtag_mmap_flags 0
-#endif
+#endif /* USE_AARCH64_MTAG_HEAP */
static __always_inline void *
tag_region (void *ptr, size_t size)
@@ -3341,7 +3341,7 @@ __libc_free (void *mem)
}
if (__glibc_unlikely (tcache_inactive ()))
- return tcache_free_init (mem);
+ return tcache_free_init (chunk2mem (p));
}
Most guarded variables are useful across architecture, keeping generic
names will reduce code
duplication for other architecture.
Another comment, if you look into this call in malloc.c and whether it can
be replaced
From
return __libc_mtag_tag_zero_region (__libc_mtag_new_tag (ptr), size);
To
return __libc_mtag_tag_zero_region (ptr, size);
Avoiding function call in parameter.
--Sunil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260326/3ef140c7/attachment-0001.htm>
More information about the Libc-alpha
mailing list