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

[enh]

On Wed, Sep 3, 2025 at 10:07 AM Rich Felker <dalias@libc.org> wrote:
>
> On Wed, Sep 03, 2025 at 02:53:55PM +0100, Yury Khrustalev wrote:
> > On Tue, Sep 02, 2025 at 11:59:32AM -0400, enh wrote:
> > > On Mon, Sep 1, 2025 at 5:51 AM Yury Khrustalev <yury.khrustalev@arm.com> 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).
> > > >
> > > > This commit also adds relevant tests for the clone() and clone3() use cases.
> > > > While the former is trivial, the latter is a bit complex since the clone3()
> > > > symbol is not public.
> > >
> > > is it time to make clone3() public? i've had a few requests over in Android too.
> > >
> > > (avoiding this kind of "oh, but for $ARCH you also have to do $TRICK"
> > > in callers being the answer to "why not just use syscall()?".)
> >
> > As far as I understand, making clone3() public will require significant
> > changes throughout the library to make sure any internal machinery that
> > exists to make sure child processes and threads are working correctly is
> > also exposed correctly. This is a big undertaking, and without
> > significant popular demand I don't think anyone would want to do that.

but no worse than the existing limitations on clone(), right?

> clone3 is largely just not useful to expose. Pretty much all of the
> things you can set through it are things that have to be forbidden
> unless you're writing a low level no-libc runtime.
>
> Probably the right thing to do is expose a fancier fork that uses
> clone3 only in fork-mode and lets you do the pidfd and cgroup stuff
> that might actually be useful.

you'll be unsurprised to hear that it's mainly cgroups that i've heard
interest in too. but coming up with a whole new interface that
everyone agrees on sounds like a significantly harder problem.

> Rich