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

[Peter Collingbourne]

On Mon, Mar 7, 2022 at 11:10 AM Mark Brown <broonie at kernel.org> wrote:
>
> 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.

I agree with Mark that there are going to be (to some extent
hypothetical) compatibility problems no matter what we do. I think a
good way to think about it is: if we need to do the same thing again
in the future (in this case, adding another mode), which design would
allow us to avoid the same potential compatibility problems? To me the
PR_GET_TCF/PR_SET_TCF control seems like the best way of avoiding
that.

Peter