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

[Rich Felker]

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:
> >
> > On Fri, Jun 20, 2025 at 11:31:34AM -0300, Adhemerval Zanella Netto wrote:
> > >
> > >
> > > On 20/06/25 10:15, Yury Khrustalev wrote:
> > > > ...
> > > > corresponding wrappers. Where the syscall() function is used, this would
> > > > already be target-specific code, and the author of such code would need
> > > > to be aware of any additional requirements and would have to take care
> > > > of them manually (in this case by using the architecture-specific function
> > > > __arm_za_disable() before invoking syscall()).
> > >
> > > I still think we should only do this for the *exported* clone call
> > > (sysdeps/unix/sysv/linux/aarch64/clone.S), and not change the internal
> > > __clone/__clone3 since from the whole discussion the kernel should
> > > handle them correctly on recent versions.
> >
> >
> > But then someone will need to remember to "fix-up" clone3 when it gets exported.
> > I believe it's better to have implementations of these syscalls aligned.
> >
> > > >
> > > > Just make things explicit, I will add a section on this to the Glibc manual.
> > > > This should also be described in Documentation/arch/arm64/sme.rst on the
> > > > kernel side at some point.
> > >
> > > 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.

My understanding was that the libc discussion here was just for the
purpose of "if you want to try to make things work ok on a range of
historic broken kernels". I would deem that important for baseline
standard functionality. It would not deem that terribly important for
new-fad-of-the-year vector ops. Applications are not going to depend
on these unconditionally anyway, but are going to look at hwcap or
whatever, so you can just turn off support for them in the kernel for
broken kernel versions.

Rich