[PATCH v4 2/2] manual: add architecture specific note on clone and clone3 syscalls

[Rich Felker]

On Mon, Sep 01, 2025 at 06:33:35PM +0200, Florian Weimer wrote:
> * Yury Khrustalev:
> 
> > +@subsection Architecture specific notes on system calls
> > +
> > +Because @code{syscall} function does not know anything about what a particular
> > +system call does or what are the ABI requirements for it, it is important to be
> > +aware of any additional requirements that the target kernel might have for
> > +certain system calls.
> > +
> > +On AArch64 systems with enabled SME extension, system calls with @var{sysno}
> > +equal to @code{SYS_clone} or @code{SYS_clone3} must be preceded with a call
> > +to the @code{__arm_za_disable()} function in order to disable ZA state of SME
> > +(see @url{https://github.com/ARM-software/abi-aa/blob/main/aapcs64/aapcs64.rst}
> > +for details) . When the @code{clone()} wrapper provided by @theglibc{} is used,
> > +this would happen automatically.
> 
> As this is discussing clone, I think you really should mention that
> using syscall for clones that are not fork-style (vfork-style, or
> thread-style) is NOT supported in general.  Not mentioning this
> important restriction implies support.

I don't see how using syscall() to call SYS_clone[3] yourself could
ever be supported unless you refrain from invoking any libc code in
the child. Internal data structures (with things like pids/tids,
tracking of thread state, etc.) are going to be left as a copy of the
parent's rather than a valid state for the child.

If the libc-provided clone() function is used, that can be supported
but then no action is needed by the caller to disable ZA state. The
libc functon can just do that itself.

So I fail to see why any documentation is needed here beyond the
existing restriction that "calling syscall(SYS_clone) yourself is
invalid and will blow up and you get to keep all the pieces".

Rich