[PATCH v5 4/4] arm64: errata: Work around early CME DVMSync acknowledgement

[Will Deacon]

On Fri, Apr 10, 2026 at 01:55:49PM +0100, Catalin Marinas wrote:
> On Fri, Apr 10, 2026 at 01:09:41PM +0100, Will Deacon wrote:
> > On Tue, Apr 07, 2026 at 11:28:44AM +0100, Catalin Marinas wrote:
> > > diff --git a/arch/arm64/kernel/process.c b/arch/arm64/kernel/process.c
> > > index 489554931231..4c328b7c79ba 100644
> > > --- a/arch/arm64/kernel/process.c
> > > +++ b/arch/arm64/kernel/process.c
> > > @@ -26,6 +26,7 @@
> > >  #include <linux/reboot.h>
> > >  #include <linux/interrupt.h>
> > >  #include <linux/init.h>
> > > +#include <linux/cpumask.h>
> > >  #include <linux/cpu.h>
> > >  #include <linux/elfcore.h>
> > >  #include <linux/pm.h>
> > > @@ -339,8 +340,41 @@ void flush_thread(void)
> > >  	flush_gcs();
> > >  }
> > >  
> > > +#ifdef CONFIG_ARM64_ERRATUM_4193714
> > > +
> > > +static void arch_dup_tlbbatch_mask(struct task_struct *dst)
> > > +{
> > > +	/*
> > > +	 * Clear the inherited cpumask with memset() to cover both cases where
> > > +	 * cpumask_var_t is a pointer or an array. It will be allocated lazily
> > > +	 * in sme_dvmsync_add_pending() if CPUMASK_OFFSTACK=y.
> > > +	 */
> > > +	if (alternative_has_cap_unlikely(ARM64_WORKAROUND_4193714))
> > > +		memset(&dst->tlb_ubc.arch.cpumask, 0,
> > > +		       sizeof(dst->tlb_ubc.arch.cpumask));
> > 
> > nit: use cpumask_clear() instead?
> 
> I tried to explain in the comment above. The memset() is on purpose to
> avoid #ifdef CPUMASK_OFFSTACK. When enabled, cpumask_var_t is a pointer
> and we want it set to NULL (for later lazy allocation) rather than
> clearing the parent's cpumask. I had the diff below initially but it
> looked uglier. Or we make the erratum dependent on !CPUMASK_OFFSTACK but
> it won't get compile coverage with defconfig.

Sorry, my mistake. I was focussing on the mm_cpumask() changes since v3
(which always seem to be embedded as part of the 'mm_struct' allocation)
and didn't realise that this memset() is operating on the TLB batch
cpumask.

So it looks like v5 is the charm :)

Will