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

[Sunil Pandey]

On Mon, Mar 30, 2026 at 1:04 AM Yury Khrustalev <yury.khrustalev@arm.com>
wrote:

> Hello Sunil,
>
> On Thu, Mar 26, 2026 at 10:22:36AM -0700, Sunil Pandey wrote:
> > On Thu, Mar 26, 2026 at 2:32 AM Yury Khrustalev <yury.khrustalev@arm.com
> >
> > wrote:
> >
> > ...
> >
> > > 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.
> > >
> > My concerns are related to changes in architecture independent files.
>
> I understand your concerns and I agree that this is not ideal that some
> target-dependent elements are included in the code that is supposed to
> be generic.
>
> However, this existed before my patch, I've only made it explicit by
> changing the name of the macro. If you insist, I could keep the generic
> name for this macro, but it would only hide the issue, not solve it.
>
>
How about renaming

USE_AARCH64_MTAG_HEAP => USE_MTAG_HEAP
USE_AARCH64_MTAG_STACK => USE_MTAG_STACK

Sunil



> We should probably use sysdeps files for such arch-dependent things,
> however this would be one of the next steps.
>
> >
> > Most guarded variables are useful across architecture, keeping generic
> > names will reduce code
> >  duplication for other architecture.
>
> Agreed, but one step at a time.
>
> >
> > 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.
>
> This is good point, but it's out of scope of this patch. I'll keep this
> in mind for the future.
>

Thanks


>
> Thanks,
> Yury
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://sourceware.org/pipermail/libc-alpha/attachments/20260330/f4599aef/attachment-0001.htm>