[PATCH v1 4/4] arm64/mte: Add userspace interface for enabling asymmetric mode

[Mark Brown]

On Mon, Mar 07, 2022 at 03:36:52PM +0000, Catalin Marinas wrote:
> On Fri, Mar 04, 2022 at 01:09:00PM -0800, Peter Collingbourne wrote:

> > And an attempt to guess the user intent from which
> > bits are set seems prone to failure and unnecessarily restrictive.
> 
> Only allowing asymmetric mode if both symmetric and async are supported
> is not that confusing. The only downside is that one cannot ask for
> asymmetric mode only but is this such a big problem? For testing one can
> always set the sysfs preferred mode to asymm. It will be some time
> before we see asymm in production.

People like to do things like run their testsuites in containers and
generally not as root which is a problem for any interface that relies
on fiddling with the system settings.  It's something people can work
around but it's not great.

Another option here would be to just not expose asymmetric mode directly
via the pcrtl() at all and just allow it if it's supported and both
sync and async are enabled.  Userspace ought to be able to tolerate
this since the preferred mode may vary depending on which CPU the task
gets scheduled on so the application may get a mix of modes if it's
requested both and it won't be able to worry about requesting async mode
since the option simply isn't there meaning it's less likely to get
specific coverage in application testsuites.

> > The only downside that I've seen mentioned is that we will end up
> > issuing more syscalls on process startup which could harm performance.

> I don't think that's the only downside. It's an ABI change as well
> w.r.t. getting the current TCF setting and asymm being invisible to an
> unaware app. The only way out I see is to make asymm a kernel choice
> when both sync and async are selected (potentially with another bit to
> opt it but without changing the TCF mask).

It's not the most lovely API but given that we're faced with choices of
what to break or bodge another kludge would be to require that a second
bit be set when enabling asymmetric mode with that bit reading as zero.
That would break old code doing a save/restore flow though so while it
helps the original problem I don't know that it's actually doing much
overall.  I think this just comes down to a question of where we end up
causing problems.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20220307/dc995092/attachment-0001.sig>