The 05/27/2020 10:55, Will Deacon wrote: > 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: > > > 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. i would not expect mte overhead if userspace processes don't map anything with PROT_MTE and don't enable tag checking with prctl. (i.e. userspace runtimes can "opt out" of mte for better power, perf and battery) is that not the case?
