Re: kernel/fork.c:3088:2: warning: clone3() entry point is missing, please fix

["Arnd Bergmann" <arnd@arndb.de>]

On Mon, Jun 30, 2025, at 12:45, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-06-30 at 12:02 +0200, Arnd Bergmann wrote:
>> Some architectures have custom calling conventions for the
>> fork/vfork/clone/clone3 syscalls, e.g. to handle copying all the
>> registers correctly when the normal syscall entry doesn't do that,
>> or to handle the changing stack correctly.
>> 
>> I see that both sparc and hexagon have a custom clone() syscall,
>> so they likely need a custom clone3() as well, while sh and
>> nios2 probably don't.
>> 
>> All four would need a custom assembler implementation in userspace
>> for each libc, in order to test the userspace calling the clone3()
>> function. For testing the kernel entry point itself, see Christian's
>> original test case[1].
>
> Thanks for the explanation. So, I guess as long as a proposed implementation
> of clone3() on sh would pass Arnd's test program, it should be good for merging?

Yes, Christian's test program should be enough for merging into
the kernel, though I would recommend also coming up with the matching
glibc patch, in order to ensure it can actually be regression tested
automatically, and to use the new features provided by glibc clone3().

Right now glibc assumes that clone3() is available on linux-5.3 or
higher and uses it to implement the normal clone() in that case,
except where the implementation is missing.

I see that at alpha, csky, parisc and microblaze have a kernel
implementation in modern Linux versions, but are missing the
glibc wrapper for it, as the kernel side was done later without
the glibc version. sparc and sh are the only ones with a glibc
port that are missing both the kernel and userspace side,
while hexagon and nios2 are not currently part of mainline glibc.

     Arnd