[PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis

[Tejas Belagod]

> -----Original Message-----
> From: Szabolcs Nagy <Szabolcs.Nagy at arm.com>
> Sent: Tuesday, June 29, 2021 2:59 PM
> To: Will Deacon <will at kernel.org>
> Cc: Catalin Marinas <Catalin.Marinas at arm.com>; Peter Collingbourne
> <pcc at google.com>; Vincenzo Frascino <Vincenzo.Frascino at arm.com>; Evgenii
> Stepanov <eugenis at google.com>; Linux ARM <linux-arm-
> kernel at lists.infradead.org>; Tejas Belagod <Tejas.Belagod at arm.com>
> Subject: Re: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on
> a per-CPU basis
> 
> The 06/29/2021 11:46, Will Deacon wrote:
> > On Mon, Jun 28, 2021 at 04:20:24PM +0100, Catalin Marinas wrote:
> > > Another option is a mapping table where async can be remapped to
> > > sync and sync to async (or even to "none" for both). That's not far
> > > from one of Peter's mte-upgrade-async proposal, we just add
> > > mte-map-async and mte-map-sync options. Most likely we'll just use
> > > mte-map-async for now to map it to sync on some CPUs but it wouldn't
> > > exclude other forced settings.
> >
> > Catalin and I discussed this offline and ended up with another option:
> > retrospectively change the prctl() ABI so that the 'flags' argument
> > accepts a bitmask of modes that the application is willing to accept.
> > This doesn't break any existing users, as we currently enforce that
> > only one mode is specified, but it would allow things like:
> >
> > 	prctl(PR_SET_TAGGED_ADDR_CTRL,
> > 	      PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC,
> > 	      0, 0, 0);
> >
> > which is actually very similar to Peter's PR_MTE_DYNAMIC_TCF proposal,
> > with the difference that I think this extends more naturally as new
> > PR_MTR_TCF_* flags are introduced.
> >
> > Then we expose a per-cpu file in sysfs (say "cpuX/mte_tcf_preferred")
> > which initially reads as "async". If the root user does, e.g.
> >
> > 	# echo "sync" > cpu1/mte_tcf_preferred
> >
> > then a task which has successfully issued a PR_SET_TAGGED_ADDR_CTRL
> > prctl() request for PR_MTE_TCF_SYNC | PR_MTE_TCF_ASYNC will run in
> > sync mode on CPU1, but async mode on other CPUs (assuming they retain the
> default value).
> >
> > We'll need to special-case PR_MTE_TCF_NONE, as that's just a shorthand
> > for "no flags" so doing PR_MTE_TCF_NONE | PR_MTE_TCF_SYNC is just the
> > same as doing PR_MTE_TCF_SYNC (which I think is already the behaviour
> > today). The only values which the sysfs files would accept today are "sync" and
> "async".
> >
> > When faced with a situation where the prctl() flags for a task do not
> > intersect with the preferred mode for a CPU on which the task is going
> > to run, the lowest bit number flag is chosen from the mask set by the
> > prctl().
> >
> > Thoughts?
> 
> i'm happy with this.
> 
> "lowest bit number" flag may not be optimal if there are many flags, but i don't
> expect many more tag check modes.
> 
> no separate TCF_NONE bit means if we later want to turn tag check off per cpu
> there is no opt-out.
> but i guess this is fine.
> 
> will armv8.7-a style asymmetric check use separate flag or TCF_SYNC |
> TCF_ASYNC may enable it?
> i see arguments either way.

If app wants to say 'I want either TCF_SYNC | TCF_ASYNC, but not TCF_ASYM' it will have to be a separate bit, right?

Thanks,
Tejas.