[PATCH v3 2/8] elf: Add a tunable to control use of tagged memory

H.J. Lu hjl.tools@gmail.com
Fri Nov 27 18:41:43 GMT 2020


On Fri, Nov 27, 2020 at 9:02 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 11/27/2020 06:54, H.J. Lu via Libc-alpha wrote:
> > On Fri, Nov 27, 2020 at 4:24 AM Richard Earnshaw
> > <Richard.Earnshaw@foss.arm.com> wrote:
> > > On 27/11/2020 11:27, Siddhesh Poyarekar wrote:
> > > > From a distribution perspective, this could be done in two phases:
> > > >
> > > > 1. Phase 1 where you ave the tunable which is disabled by default and no
> > > > marker present.  This makes tagging available to those who want to opt-in
> > > >
> > > > 2. Phase 2 is where the tunable is now enabled by default and can be
> > > > overridden with an opt-out marker.  Running this opt-out binary on the
> > > > older version is safe (and shouldn't need an ABI bump) since tunables
> > > > are disabled by default.
> > > >
> > > > Does that make sense?  If not then I'd really like to see a more
> > > > detailed description of how you intend to roll this out.
> > > >
> > > > Siddhesh
> > >
> > > Yes, you've captured my thoughts and summarised it better that I was
> > > doing myself.  Thank you.
> > >
> >
> > We need a plan for binary marker first.
>
> if we enable heap tagging in those two phases then the first
> phase has no abi commitment (tunables are not abi stable).
>
> heap tagging will not be very useful in phase 1 but at least
> users can start testing it and report back issues. (assuming
> they have hardware or emulator.)
>
> i was hoping we can have an abi stable env var ui, but i'm
> fine with tunables only since that sounds the safest.
> (if we wait for the marking design and binutils etc support
> then we have less chance to see deployment problems early.)

We should try to get it right if it will be installed as the system glibc.

-- 
H.J.


More information about the Libc-alpha mailing list