All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Carl Worth <carl@os.amperecomputing.com>
Cc: Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, Taehyun Noh <taehyun@utexas.edu>,
	Peter Collingbourne <pcc@google.com>
Subject: Re: [PATCH v2 1/2] arm64: mte: Clarify kernel MTE policy and manipulation of TCO
Date: Mon, 19 Jan 2026 18:17:28 +0000	[thread overview]
Message-ID: <aW51OPBNsydlJS30@arm.com> (raw)
In-Reply-To: <20251030-mte-tighten-tco-v2-1-e259dda9d5b3@os.amperecomputing.com>

+ Peter as he contributed the original patch for skipping PSTATE.TCO
clearing.

On Thu, Jan 15, 2026 at 03:07:17PM -0800, Carl Worth wrote:
> From: Taehyun Noh <taehyun@utexas.edu>
> 
> The kernel's primary knob for controlling MTE tag checking is the
> PSTATE.TCO bit (tag check override). TCO is enabled (which,
> confusingly _disables_ tag checking) by the hardware at the time of an
> exception. Then, at various times, when the kernel needs to enable
> tag-checking it clears TCO, (which in turn allows TCF0 or TCF to
> control whether tag-checking occurs).
> 
> Some of the TCO manipulation code is unclear or perhaps confusing.
> 
> Make the code more clear by introducing a new function
> user_uses_tagcheck which captures the existing condition for testing
> whether tag checking is desired. This new function includes
> significant new comments to help explain the logic.
> 
> Also fix the confusing naming by renaming mte_disable_tco_entry() to
> set_kernel_mte_policy(). This function does not necessarily disable
> TCO, but does so only conditionally in the case of KASAN HW TAGS. The
> new name accurately describes the purpose of the function.
> 
> This commit should have no behavioral change.
> 
> Signed-off-by: Taehyun Noh <taehyun@utexas.edu>
> Co-developed-by: Carl Worth <carl@os.amperecomputing.com>
> Signed-off-by: Carl Worth <carl@os.amperecomputing.com>
> ---
>  arch/arm64/include/asm/mte.h     | 40 +++++++++++++++++++++++++++++++++-------
>  arch/arm64/kernel/entry-common.c |  4 ++--
>  arch/arm64/kernel/mte.c          |  2 +-
>  3 files changed, 36 insertions(+), 10 deletions(-)
> 
> diff --git a/arch/arm64/include/asm/mte.h b/arch/arm64/include/asm/mte.h
> index 6d4a78b9dc3e..fccb51b2abb0 100644
> --- a/arch/arm64/include/asm/mte.h
> +++ b/arch/arm64/include/asm/mte.h
> @@ -224,7 +224,35 @@ static inline bool folio_try_hugetlb_mte_tagging(struct folio *folio)
>  }
>  #endif
>  
> -static inline void mte_disable_tco_entry(struct task_struct *task)
> +static inline bool user_uses_tagcheck(struct task_struct *task)

The naming is not entirely correct since the user may have enabled
asynchronous tag checks. They are still checks.

> +{
> +	/*
> +	 * To decide whether userspace wants tag checking we only look
> +	 * at TCF0 (SCTLR_EL1.TCF0 bit 0 is set for both synchronous
> +	 * or asymmetric mode).
> +	 *
> +	 * There's an argument that could be made that the kernel
> +	 * should also consider the state of TCO (tag check override)
> +	 * since userspace does have the ability to set that as well,
> +	 * and that could suggest a desire to disable tag checking in
> +	 * spite of the state of TCF0. However, the Linux kernel has
> +	 * never historically considered the userspace state of TCO,
> +	 * (so changing this would be an ABI break), and the hardware
> +	 * unconditionally sets TCO when an exception occurs
> +	 * anyway.

This behaviour around user TCO is already documented in
Documentation/arch/arm64/memory-tagging-extension.rst.

> +	 *
> +	 * So, again, here we look only at TCF0 and do not consider
> +	 * TCO.
> +	 */
> +	return (task->thread.sctlr_user & (1UL << SCTLR_EL1_TCF0_SHIFT));
> +}
> +
> +/*
> + * Set the kernel's desired policy for MTE tag checking.
> + *
> + * This function should be used right after the kernel entry.
> + */
> +static inline void set_kernel_mte_policy(struct task_struct *task)
>  {
>  	if (!system_supports_mte())
>  		return;
> @@ -232,15 +260,13 @@ static inline void mte_disable_tco_entry(struct task_struct *task)
>  	/*
>  	 * Re-enable tag checking (TCO set on exception entry). This is only
>  	 * necessary if MTE is enabled in either the kernel or the userspace
> -	 * task in synchronous or asymmetric mode (SCTLR_EL1.TCF0 bit 0 is set
> -	 * for both). With MTE disabled in the kernel and disabled or
> -	 * asynchronous in userspace, tag check faults (including in uaccesses)
> -	 * are not reported, therefore there is no need to re-enable checking.
> +	 * task. With MTE disabled in the kernel and disabled or asynchronous
> +	 * in userspace, tag check faults (including in uaccesses) are not
> +	 * reported, therefore there is no need to re-enable checking.
>  	 * This is beneficial on microarchitectures where re-enabling TCO is
>  	 * expensive.
>  	 */
> -	if (kasan_hw_tags_enabled() ||
> -	    (task->thread.sctlr_user & (1UL << SCTLR_EL1_TCF0_SHIFT)))
> +	if (kasan_hw_tags_enabled() || user_uses_tagcheck(task))
>  		asm volatile(SET_PSTATE_TCO(0));
>  }

TBH, I'm fine with leaving the logic in this function without
introducing a new user_uses_tagcheck() but not strongly opposed to it
with better naming.

That said, the set_kernel_mte_policy() naming looks too broad. The
policy somehow implies tag check mode, fault behaviour. All it does is
dealing with PSTATE.TCO.

-- 
Catalin


  reply	other threads:[~2026-01-19 18:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-15 23:07 [PATCH v2 0/2] arm64: mte: Improve performance by explicitly disabling unwanted tag checking Carl Worth
2026-01-15 23:07 ` [PATCH v2 1/2] arm64: mte: Clarify kernel MTE policy and manipulation of TCO Carl Worth
2026-01-19 18:17   ` Catalin Marinas [this message]
2026-01-20 19:44     ` Taehyun Noh
2026-01-15 23:07 ` [PATCH v2 2/2] arm64: mte: Set TCMA1 whenever MTE is present in the kernel Carl Worth
2026-01-19 17:57   ` Catalin Marinas
2026-01-22 10:23   ` Usama Anjum
2026-01-22 11:49     ` Catalin Marinas
2026-01-27 11:39 ` [PATCH v2 0/2] arm64: mte: Improve performance by explicitly disabling unwanted tag checking Will Deacon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=aW51OPBNsydlJS30@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=carl@os.amperecomputing.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=pcc@google.com \
    --cc=taehyun@utexas.edu \
    --cc=will@kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.