All of lore.kernel.org
 help / color / mirror / Atom feed
From: Catalin Marinas <catalin.marinas@arm.com>
To: Fuad Tabba <fuad.tabba@linux.dev>
Cc: Will Deacon <will@kernel.org>,
	linux-arm-kernel@lists.infradead.org,
	Marc Zyngier <maz@kernel.org>, Oliver Upton <oupton@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Suzuki K Poulose <suzuki.poulose@arm.com>,
	Mark Brown <broonie@kernel.org>,
	kvmarm@lists.linux.dev, linux-kernel@vger.kernel.org,
	Fuad Tabba <tabba@google.com>
Subject: Re: [PATCH v3] arm64: Don't read GMID_EL1 when MTE is disabled
Date: Mon, 24 Aug 2026 21:29:02 +0100	[thread overview]
Message-ID: <aoypji6EJ8zToWvh@arm.com> (raw)
In-Reply-To: <20260824184155.2644646-1-fuad.tabba@linux.dev>

On Mon, Aug 24, 2026 at 07:41:55PM +0100, Fuad Tabba wrote:
> +/*
> + * Reading GMID_EL1 when the kernel has disabled MTE traps to EL2, and the raw
> + * ID_AA64PFR1_EL1 reflects neither CONFIG_ARM64_MTE nor the cmdline override.
> + */
> +static inline bool gmid_el1_accessible(u64 pfr1)
> +{
> +	if (!IS_ENABLED(CONFIG_ARM64_MTE))
> +		return false;
> +
> +	pfr1 &= ~id_aa64pfr1_override.mask;
> +	pfr1 |= id_aa64pfr1_override.val;
> +
> +	return id_aa64pfr1_mte(pfr1);
> +}

Can this function not use __read_sysreg_by_encoding() directly and not
get an argument at all? We'd get the override from that function rather
than open-coding it here. Eventually, once we get Suzuki's clamping fix,
it also ensures we won't be able to bump the MTE version to unsafe
values (but that's a different fix from this one).

If you are worried about additional trapping of the MRS, we should go
for Will's improvement to always read the cached values in
__read_sysreg_by_encoding().

-- 
Catalin

  parent reply	other threads:[~2026-08-24 20:29 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-08-24 18:41 [PATCH v3] arm64: Don't read GMID_EL1 when MTE is disabled Fuad Tabba
2026-08-24 18:56 ` sashiko-bot
2026-08-24 19:54   ` Fuad Tabba
2026-08-24 20:29 ` Catalin Marinas [this message]
2026-08-24 22:29   ` Fuad Tabba
2026-08-25 14:14     ` Will Deacon
2026-08-25 14:46       ` Fuad Tabba
2026-08-26 11:06         ` Catalin Marinas
2026-08-27 10:23           ` 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=aoypji6EJ8zToWvh@arm.com \
    --to=catalin.marinas@arm.com \
    --cc=broonie@kernel.org \
    --cc=fuad.tabba@linux.dev \
    --cc=kvmarm@lists.linux.dev \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=maz@kernel.org \
    --cc=oupton@kernel.org \
    --cc=suzuki.poulose@arm.com \
    --cc=tabba@google.com \
    --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.