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

[Adhemerval Zanella Netto]

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.