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

From: Szabolcs Nagy <szabolcs.nagy@arm.com>
To: Catalin Marinas <catalin.marinas@arm.com>
Cc: Peter Collingbourne <pcc@google.com>,
	Will Deacon <will@kernel.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Evgenii Stepanov <eugenis@google.com>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>,
	Tejas Belagod <Tejas.Belagod@arm.com>
Subject: Re: [PATCH v5] arm64: mte: allow async MTE to be upgraded to sync on a per-CPU basis
Date: Fri, 25 Jun 2021 10:22:53 +0100	[thread overview]
Message-ID: <20210625092253.GJ13058@arm.com> (raw)
In-Reply-To: <20210624165228.GB25097@arm.com>

The 06/24/2021 17:52, Catalin Marinas wrote:
> Thanks. Is there any MTE support in mainline glibc? If not, we may have
> another chance of adjusting the ABI.

glibc exposed heap tagging via an env var mechanism
that can change between glibc releases, i.e. not
abi stable, and we have no real contract about how
the prctl can be used on top of glibc (see e.g. the
multi-thread issue).

we don't expect the async mode to be very useful on
glibc based linux systems.

changing async mode is unlikely to affect anything
in userspace at this point.

> It's a pretty complex step over (or emulate), so I wouldn't go there.
> The user signal handler could disable tag checking altogether
> (PSTATE.TCO) and continue.

ah yes, disabling checks makes more sense if user
wants to continue.

> The question is more about whether we still want to keep the current
> user program choice of sync vs async (vs the new asymmetric mode in
> 8.7). If the user wouldn't care, we just override it from the kernel
> without any additional PR_ flag for opting in (or out).

i think the usefulness of pure async mode is very
limited, and we haven't seen valid use-cases for it.

> > the per cpu setting is a bit nasty: can the kernel decide which cpu
> > should use sync and which async? or a privileged user will have to
> > fiddle with sysfs settings on every system to make this useful?
> 
> The proposed interface is sysfs. I think that's not relevant to the user
> application since it wouldn't have control over it anyway. What's
> visible is that it cannot rely on the mode it requested, not even for
> the lifetime of a thread (as it may migrate between CPUs). Do you see
> any issues with this? For Android, it's probably fine but if other
> programs cannot cope (or need the specific mode requested), we'd need a
> new control (for opt-in or opt-out).

i don't see any issues with changing async mode.

i assume the prctl get operation would return whatever
was the prctl setting for the thread and not try to
expose the per cpu architectural state.

i assume async vs sync fault can be distinguished via
the SEGV_MTE{A,S}ERR si_code.

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