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

enh enh@google.com
Tue Jun 24 15:08:23 GMT 2025


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?

why isn't the right fix "the kernel always does this", rather than
just for the current subset of flags?

seems like that would address your own concerns with clone3() too...

> > require further handling wrt to lazy saving.  It still not clear to me
> > which kind of usage are not fully safe on recent kernels.
> >
> > >
> > > Will be sending v3 shortly.
>
> v3 submitted, I suggest that we continue conversation there:
> https://inbox.sourceware.org/libc-alpha/20250620132041.400264-1-yury.khrustalev@arm.com/
>
> Thanks,
> Yury
>


More information about the Libc-alpha mailing list