Re: [PATCH v4 2/2] arm64: Don't read GMID_EL1 when MTE is disabled

[Will Deacon <will@kernel.org>]

On Fri, Aug 28, 2026 at 11:50:12AM +0100, Catalin Marinas wrote:
> On Thu, Aug 27, 2026 at 01:56:35PM +0100, Will Deacon wrote:
> > On Tue, Aug 25, 2026 at 05:42:19PM +0100, Fuad Tabba wrote:
> > > +/* No ID register reflects CONFIG_ARM64_MTE. */
> > > +static inline bool gmid_el1_accessible(void)
> > > +{
> > > +	if (!IS_ENABLED(CONFIG_ARM64_MTE))
> > > +		return false;
> > > +
> > > +	return id_aa64pfr1_mte(__read_sysreg_by_encoding(SYS_ID_AA64PFR1_EL1));
> > 
> > I'm planning to internalise __read_sysreg_by_encoding() into cpufeature.c
> > so I'd prefer to avoid adding another user of it, if possible. In this case,
> > __cpuinfo_store_cpu() has already read the thing, so all it needs is the
> > override logic (but see below).
> 
> That's a valid point.
> 
> > > @@ -502,7 +502,7 @@ static void __cpuinfo_store_cpu(struct cpuinfo_arm64 *info)
> > >  	info->reg_id_aa64smfr0 = read_cpuid(ID_AA64SMFR0_EL1);
> > >  	info->reg_id_aa64fpfr0 = read_cpuid(ID_AA64FPFR0_EL1);
> > >  
> > > -	if (id_aa64pfr1_mte(info->reg_id_aa64pfr1))
> > > +	if (gmid_el1_accessible())
> > >  		info->reg_gmid = read_cpuid(GMID_EL1);
> > 
> > I'm not sure this is safe. For the boot CPU, __cpuinfo_store_cpu() is
> > called before init_cpu_features(), so the arm64_ftr_regs[] array hasn't
> > been sorted and we can't call get_arm64_ftr_reg() reliably.
> 
> We no longer sort this array at boot-time, we just check that it's
> pre-sorted.

Fair enough, but I still don't think we should access it until we've
checked that.

> > In fact, it
> > doesn't even look like the overrides will have been processed.
> 
> init_feature_override() runs from early_map_kernel() but yes,
> init_cpu_ftr_reg() hasn't been called yet to vet the override. Suzuki's
> patch was adding extra checks in __read_sysreg_by_encoding() but if we
> drop that patch (and function eventually), better not to rely on it.

Right, and we have to be really careful here with things like the new
"nohaft" override because otherwise we could accidentally end up
thinking we have hardware dirty on CPUs that don't have it. In other
words, it's not just about people passing bonkers settings on the cmdline.

> So I don't think we have a correctness issue here but I don't mind v5
> either. I'll go and check.

Thanks.

Will