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

[Szabolcs Nagy]

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.