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

From: Catalin Marinas <catalin.marinas@arm.com>
To: Szabolcs Nagy <szabolcs.nagy@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 13:01:37 +0100	[thread overview]
Message-ID: <20210625120137.GC20835@arm.com> (raw)
In-Reply-To: <20210625092253.GJ13058@arm.com>

On Fri, Jun 25, 2021 at 10:22:53AM +0100, Szabolcs Nagy wrote:
> 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.

Thanks, that's useful. I guess since the _MTAG_ENABLE tunable is not
ABI, the user app can't rely on what the glibc has configured. Arguably,
since it's driven from outside the application (env), we could say the
same for sysfs, though for the glibc case, the user app is still be able
to override it before the first thread is created (or per-thread). I
assume glibc only issues the prctl() once, not for every new thread.

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

Yes.

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

Indeed.

So we can document that the mode requested by the app is an indication,
the system may change it to another value (and back-port documentation
to 5.10). If we get a request from developers to honour a specific mode,
we can add a new PR_MTE_TCF_EXACT bit or something but it's not
essential we do it now.

So if we allow the kernel to change the user requested mode (via sysfs),
I think we still have two more issues to clarify:

1. Do we allow only "upgrade" (for some meaning of this) or sysfs can
   downgrade to a less strict mode. I'd go for upgrade here to a
   stricter check as in Peter's patch.

2. Should the sysfs upgrade the PR_MTE_TCF_NONE? _MTAG_ENABLE does that,
   so I'd say yes.

Any other thoughts are welcome.

-- 
Catalin

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