Re: aarch64: Memory tagging modes proposal
Adhemerval Zanella Netto <[email protected]>
| Newsgroups | gmane.comp.lib.glibc.alpha |
|---|---|
| Organization | Linaro |
| Message-ID | <[email protected]> |
On 26/08/26 05:43, Yury Khrustalev wrote: > On Tue, Aug 25, 2026 at 10:07:31AM -0300, Adhemerval Zanella Netto wrote: >> >> ... >> >> The deeper problem is that the tunable answers two orthogonal questions >> with one value: >> >> * which fault mode? >> * is heap tagging enabled for unmarked binaries? > > Technically, these are orthogonal, but > > | ---------------------------- | > | on | sync | async | etc... | > | ---------------------------- | > | off | -- | -- | -- | > | ---------------------------- | > > there is only one dimension of meaningful combinations. > >> Which means neither can be expressed independently. > > Can you give an example that cannot be expressed? > >> An admin who wants heap >> tagging on unmarked binaries but has no opinion on mode to select > > What do you mean by "has no option for mode to select"? Tunable allows > you to select any mode. And unless mode is off, I don't see any issue > here. Right, so the tunable enables 'heap' tagging for unmarked binaries *and* selects the mode for marked ones. I think this works where only heap tagging have this implicit setup, but it does not give us much room to extend it (say we want to add opt-in MTE support for a different feature, and it rules out the opt-in MTE stack/global enablement). And most of projects using MTE are allocators or indirectly using compiler instrumentation, so adding extensibility does not seems a pressing issue either. > >> , it will >> always need to use the kernel default. > > Nobody has to use kernel default mode unless they want to. Choose > tunable value that works for your use case and use it.