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

[Adhemerval Zanella Netto]

On 20/06/25 10:15, Yury Khrustalev wrote:
> Hi everyone,
> 
> Replying here including everyone involved in multiple sub-threads that
> originated from this patch.
> 
> There's been a lot of comments on whether we need to call the Glibc's
> equivalent of __arm_za_disable() in the assembly wrappers that Glibc
> has for SYS_clone and SYS_clone3 system calls for the AArch64 target.
> 
> The gist of it is that it's difficult to reliably work out when this
> function may not be called, while calling it would be NOP when it is
> not needed, hence it's correct to call it to ensure that whatever state
> is produced as a result of a subsequent system call is consistent with
> respect to SME specifics.
> 
> One particular comment from Florian about cases when the aforementioned
> system calls are invoked directly via the syscall() function was spot on.
> Indeed, there are many usages of SYS_clone like that.
> 
> For this, I believe, we should do the following. Where SYS_clone (and
> possibly SYS_clone3 in the future) are used via the Glibc wrapper, we
> should help people write portable code, and therefore we should take
> care of any architecture-specific nuances in the implementation of the
> 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.

> 
> 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
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.
> 
> Hope this helps,
> Yury
>