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

[enh]

On Fri, Sep 19, 2025 at 5:09 AM Yury Khrustalev <yury.khrustalev@arm.com> wrote:
>
> * Elliott, Rich
>
> On Mon, Sep 01, 2025 at 10:51:11AM +0100, Yury Khrustalev wrote:
> > This change adds a call to the __arm_za_disable() function immediately
> > before the SVC instruction inside clone() and clone3() wrappers. This
> > sets the ZA state of SME to "off" on return from these functions (for
> > both the child and the parent).
>
> I hope that the explanation provided in the commit message in this patch
> addresses the questions raised earlier. So far, there was one adjacent
> question about making clone3() public. Can I ask if you have any further
> concerns or questions from the point of view of bionic or musl? I'd like
> to go ahead with this patch, if not.

i think the "make clone3() public" question is orthogonal. (and
probably something where Android will just have to go first, with this
being another example...)

it still seems to me like the commit message here, specifically

> However, in certain cases, the kernel may ensure that a "child" doesn't
> start in an incorrect state. This is what is done by the recent change
> included in 6.16 kernel [5]. This is not enough to ensure that code that
> uses clone() and clone3() function conforms to [1] when it runs on a
> system that provides SME, hence this change.

conflicts with the commit message [5], specifically the last clause of
the last sentence of

> Ideally we'd require that userspace ensures that a task is in the "ZA
> off" state (with PSTATE.ZA==0 and TPIDR2_EL0==NULL) prior to issuing a
> clone syscall, and have the kernel force this state for new threads.
> Unfortunately, contemporary C libraries do not do this, and simply
> forcing this state within the implementation of clone would break
> fork().

?

(also it's been long enough since this last came up that i've
forgotten why there isn't the corresponding bionic clone() change...)

> Thanks,
> Yury
>