Re: [PATCH v8 4/4] Documentation: document the preferred tag checking mode feature

From: Catalin Marinas <catalin.marinas@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>,
	Evgenii Stepanov <eugenis@google.com>,
	Szabolcs Nagy <szabolcs.nagy@arm.com>,
	Tejas Belagod <Tejas.Belagod@arm.com>,
	linux-arm-kernel@lists.infradead.org
Subject: Re: [PATCH v8 4/4] Documentation: document the preferred tag checking mode feature
Date: Thu, 1 Jul 2021 18:04:50 +0100	[thread overview]
Message-ID: <20210701170450.GC12484@arm.com> (raw)
In-Reply-To: <20210630231509.3773172-5-pcc@google.com>

On Wed, Jun 30, 2021 at 04:15:09PM -0700, Peter Collingbourne wrote:
> +Per-CPU preferred tag checking mode
> +-----------------------------------
> +
> +On some CPUs the performance of MTE in stricter tag checking modes
> +is similar to that of less strict tag checking modes. This makes it
> +worthwhile to enable stricter checks on those CPUs when a less strict
> +checking mode is requested, in order to gain the error detection
> +benefits of the stricter checks without the performance downsides. To
> +support this scenario, a privileged user may configure a stricter
> +tag checking mode as the CPU's preferred tag checking mode.
> +
> +The preferred tag checking mode for each CPU is controlled by
> +``/sys/devices/system/cpu/cpu<N>/mte_tcf_preferred``, to which a
> +privileged user may write the value ``async`` or ``sync``.  The default
> +preferred mode for each CPU is ``async``.
> +
> +To allow a program to potentially run in the CPU's preferred tag
> +checking mode, the user program may set multiple tag check fault mode
> +bits in the ``flags`` argument to the ``prctl(PR_SET_TAGGED_ADDR_CTRL,
> +flags, 0, 0, 0)`` system call. If the CPU's preferred tag checking
> +mode is in the task's set of provided tag checking modes (this will
> +always be the case at present because the kernel only supports two
> +tag checking modes, but future kernels may support more modes), that
> +mode will be selected. Otherwise, one of the modes in the task's mode
> +set will be selected in a currently unspecified manner.

I'm ok with leaving this undefined (it's in the spirit of many
architecture features ;)). In practice we may choose async or asym over
sync but the user shouldn't care if it passed multiple flags.

-- 
Catalin

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