[PATCH v2 0/1] aarch64: clear ZA state of SME before clone and clone3

[Rich Felker]

On Mon, Jun 30, 2025 at 06:27:44PM +0100, Yury Khrustalev wrote:
> Hi everyone,
> 
> First of all, apologies for not writing a coherent response before. This is what
> happens when I try to work on several things in parallel using fork() in my head
> and not paying attention to the consistency of the ZA state of SME in my head.
> 
> Also, sorry for a delayed response, I was on holiday last week.
> 
> ** Adhemerval, Elliott, Rich
> 
> On Tue, Jun 24, 2025 at 11:44:59AM -0400, Rich Felker wrote:
> > On Tue, Jun 24, 2025 at 11:08:23AM -0400, enh wrote:
> > > On Fri, Jun 20, 2025 at 11:13 AM Yury Khrustalev
> > > <yury.khrustalev@arm.com> wrote:
> > ...
> > > >
> > > > > Please make it clear what kind of combination of flags/arguments does not
> > > >
> > > > To list all such combinations would be a significant undertaking. This is why
> > > > we want this patch: to cover all possible cases without exploring each single
> > > > one of them.
> > > 
> > > i have to say, you're not exactly persuading me that this shouldn't
> > > just be in the kernel instead. remind me why you want to do this in
> > > all the libcs again?
> > 
> > I have not heard any good reason. This is my position too. Libc must
> > not be required to do anything here, because the user could be using a
> > libc older than the kernel and older than the application that's using
> > the new register file. The kernel which adds support for expanded
> > register file is *always*, *100%* responsible for doing whatever is
> > needed to make the addition of the new register file non-ABI-breaking.
> > And in the case of this stuff, that includes performing the
> > lazy-save-and-clear at *all* fork/clone operations, kernel-side.
> 
> There are limits to what kernel can do compared to userspace. In userspace,
> we can call __arm_za_disable() (see section about this function in [1])
> but we can't do this on the kernel side. This function does 3 things:
> 
>  (a) Save ZA buffer by calling __arm_tpidr2_save() (see [1])
>  (b) Set TPIDR2_EL0 to null
>  (c) Set PSTATE.ZA to 0
> 
> and the kernel can only do the last 2 things (b) and (c) because it never reads
> or writes the ZA save buffer and it never uses the contents of TPIDR2 directly.

That's a matter of policy choice, not "can't". The kernel absolutely
can do what's in the body of __arm_tpidr2_save, namely loading the
address of the save buffer from TPIDR2_EL0 and dumping the register
file at that location.

Rich