On Tue, May 26, 2020 at 07:11:53PM -0700, Patrick Daly wrote: > On Fri, May 22, 2020 at 11:37:15AM +0100, Catalin Marinas wrote: > > On Thu, May 21, 2020 at 10:57:10PM -0700, Patrick Daly wrote: > > > On Mon, May 18, 2020 at 06:20:55PM +0100, Catalin Marinas wrote: > > > > On Mon, May 18, 2020 at 12:31:03PM +0100, Will Deacon wrote: > > > > > On Mon, May 18, 2020 at 12:26:30PM +0100, Vladimir Murzin wrote: > > > > > > On 5/15/20 6:16 PM, Catalin Marinas wrote: > > > > > > > diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt > > > > > > > index f2a93c8679e8..7436e7462b85 100644 > > > > > > > --- a/Documentation/admin-guide/kernel-parameters.txt > > > > > > > +++ b/Documentation/admin-guide/kernel-parameters.txt > > > > > > > @@ -373,6 +373,10 @@ > > > > > > > arcrimi= [HW,NET] ARCnet - "RIM I" (entirely mem-mapped) cards > > > > > > > Format: <io>,<irq>,<nodeID> > > > > > > > > > > > > > > + arm64.mte_disable= > > > > > > > + [ARM64] Disable Linux support for the Memory > > > > > > > + Tagging Extension (both user and in-kernel). > > > > > > > + > > > > > > > > > > > > Should it really to take parameter (on/off/true/false)? It may lead to expectation > > > > > > that arm64.mte_disable=false should enable MT and, yes, double negatives make it > > > > > > look ugly, so if we do need parameter, can it be arm64.mte=on/off/true/false? > > > > > > > > > > I don't think "performance analysis" is a good justification for this > > > > > parameter tbh. We don't tend to add these options for other architectural > > > > > features, and I don't see why MTE is any different in this regard. > > > > > > > > There is an expectation of performance impact with MTE enabled, > > > > especially if it's running in synchronous mode. For the in-kernel MTE, > > > > we could add a parameter which sets sync vs async at boot time rather > > > > than a big disable knob. It won't affect user space however. > > > > > > > > The other 'justification' is if your hardware has weird unexpected > > > > behaviour but I'd like this handled via errata workarounds. > > > > > > > > I'll let the people who asked for this to chip in ;). I agree with you > > > > that we rarely add these (and I rejected a similar option a few weeks > > > > ago on the AMU patchset). > > > > > > We've been looking into other ways this on/off behavior could be achieved. > > > > The actual question here is what the on/off behaviour is needed for. We > > can figure out the best mechanism for this once we know what we want to > > achieve. My wild guess above was performance analysis but that can be > > toggled by either kernel boot parameter or run-time sysctl (or just the > > Kconfig option). > > > > If it is about forcing user space not to use MTE, we may look into some > > other sysctl controls (we already have one for the tagged address ABI). > > We want to allow the end user to be able to easily "opt out" of MTE in favour > of better power, perf and battery life. Who is "the end user" in this case? If MTE is bad enough for power, performance and battery life that we need a kill switch, then perhaps we shouldn't enable it by default and the few people that want to use it can build a kernel with it enabled. However, then I don't really see what MTE buys you over the existing KASAN implementations. I thought the general idea was that you could run in the (cheap) "async" mode, and then re-run in the more expensive "sync" mode to further diagnose any failures. That model seems to work well with these patches, since reporting is disabled by default. Are you saying that there is a significant penalty incurred even when reporting is not enabled? Anyway, we don't offer global runtime/cmdline switches for the vast majority of other architectural features -- instead, we choose a sensible default, and I think we should do the same here. Will
