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
next prev parent 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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox