[PATCH 2/2] malloc: change tunable glibc.mem.tagging to glibc.mem.aarch64_mte

[Sunil Pandey]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260325/55d82a57/attachment.htm>