Re: [PATCH v3 00/13] GLIBC LoongArch PATCHES

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 11/05/2022 03:57, Arnd Bergmann wrote:
> On Tue, May 10, 2022 at 9:37 PM Florian Weimer via Libc-alpha
> <libc-alpha@sourceware.org> wrote:
>>
>>> GCC and Binutils Loongarch parts have been into GNU Open Source community.
>>> Loongarch kernal may be no problem on 5.19:
>>
>> It seems that the Linux 5.19 release date could be really close to the
>> glibc 2.36 release date, or even after it.  I think we wouldn't want to
>> release with an ABI whose kernel interface is not in a mainline kernel
>> yet.
>>
>> We have the option to backdate ABIs, so we could release the port with a
>> GLIBC_2.36 ABI baseline in glibc 2.37.
>>
>> Or we could merge the port now, and back it out once more if Linux 5.19
>> does not get released in time.
>>
>> Maybe it's sufficient if the Linux port makes it to mainline during the
>> 5.19 rc phase?
>>
>> Thoughts?
> 
> From the kernel side, there is only one open question on the ABI:
> either this will include both clone() and clone3(), or just clone3().
> 
> This is a surprisingly hard decision. Normally the policy in the kernel
> is that new architectures only get the latest syscall interface, dropping
> earlier syscalls in favor of backward-compatible new interfaces.
> 
> For clone3(), this may not work out because
> - clone3 requires knowing the stack frame size for the child, but
>   when emulating clone() in libc, that information may not be there.
>   We need to work around this by allowing clone3 to be called without
>   a size argument

The clone is used internally without a stack only for fork
(sysdeps/unix/sysv/linux/arch-fork.h) and loongarch seems to be using
__ASSUME_CLONE_DEFAULT and exporting __NR_clone as a distinct syscall
(220).

> - some other architectures still don't implement clone3() since we
>   are missing the assembly bits for it. So unlike the other recently
>   added calls, there is no minimum kernel version that guarantees clone3
>   to be available.

If I understood correctly, Intel has added clone3 support on glibc mainly
to implement full CET (since it required stack size).  As far as I know
there is no pressing requirement to use clone3 internally, neither to
export as we did for clone; besides to support an new ABI that only 
defines clone3.

> - the seccomp/bfp infrastructure in the kernel cannot currently
>   introspect indirect syscall arguments. This has to be added at
>   some point anyway, but until then the chrome sandbox disallows
>   the clone3 syscall.
> 
> The easy way out of course is to include both in the kernel, though
> this feels like taking a step backwards. If libc developers feel strongly
> either way, please also reply on the kernel thread so we can come
> to a consensus more quickly.

I think if kernel allows fork like call for clone3, where if no starting
function is set there is no need for stack or stack size; we can adapt
internally fork to use __clone_internal (which first try to use clone3
and then fallbacks to clone).

Even for x86_64 and i686, clone3 is not used for fork (only for
pthread_create and posix_spawn).

> 
> There is still another open discussion that blocks merging the
> loongarch kernel port, but that is only for the bootloader and not
> visible to libc. We should merge it as soon as we have concluded
> both points, but it's unclear if that happens before the merge
> window.
> 
>       Arnd