[PATCH v4 2/2] manual: add architecture specific note on clone and clone3 syscalls
Yury Khrustalev
yury.khrustalev@arm.com
Tue Sep 2 12:05:24 GMT 2025
On Mon, Sep 01, 2025 at 12:46:11PM -0400, Rich Felker wrote:
> 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.
> > >
> > > ...
** Florian
> > 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 agree that we should mention this, however, I've looked through the
manual and can't find anything that would imply that clones that are
not fork-style are supported in general. It feels like this important
bit should've been mentioned somewhere else in the manual, e.g. in a
section that describes clone() but we don't seem to have any.
> > ...
** Rich
> 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.
Agreed.
> 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".
Is this existing restriction documented anywhere?
Kind regards,
Yury
More information about the Libc-alpha
mailing list