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

[Catalin Marinas <catalin.marinas@arm.com>]

On Tue, Jun 29, 2021 at 03:31:26PM +0100, Tejas Belagod wrote:
> > 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.

If some CPU in the system has an erratum that requires TCF_NONE, I'd
rather disable MTE altogether (via a kernel patch).

> > 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?

Will and I talked about this as well and we decided that it's better to
have a separate TCF_ASYM bit. So SYNC|ASYNC won't be "upgradable" to
ASYM.

-- 
Catalin

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel