From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x22d.google.com (mail-oi1-x22d.google.com [IPv6:2607:f8b0:4864:20::22d]) by sourceware.org (Postfix) with ESMTPS id 938813850413 for ; Wed, 11 May 2022 13:17:14 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 938813850413 Received: by mail-oi1-x22d.google.com with SMTP id n24so2615719oie.12 for ; Wed, 11 May 2022 06:17:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=q6rSjjoSUfRmhlOj+PNzqQtql9kQdEuXi2f5/GWgtEU=; b=r9J12/Mf8C0tWcfn+2BW+hWDPysd0Rv0OrqYkZJT3K/ntJ0dVVZpREhEqrLqpuVKTt Zy/jl4OltsTpOHIjFROXIhSGPgOK0NWEqHe64RijWIS3fLLTrg/mjTywNfcINGeBCmq5 6nVpkFP4Iv5QOD14eBzD81h/nrDPfxyywTFtqI4+nYzJrhES+HHdSgEywjAcRYvRFego vQroVXEYP9W55x1UJv5LjMKazAxadW0w5Dm02ckpbiY0ReAQ0NINXfqBNyTnZre4dNOK pl91BgisHaFzAl7DsEgB8vv+JrzVcPZGWRIkZNJH0WdSO0Ph5OQZlp3OqTUm8qu63iT9 7HoA== X-Gm-Message-State: AOAM5326jCOqVPYLEclg+vrDc7fvz9DrHs6HfZcrMz9LT/0VN/dqd7Xk +Os0n76Ic6DYvZR1KqhV6O8f959JGtiU4w== X-Google-Smtp-Source: ABdhPJw5W/ilpIVv7nGZFq6L5IrKR9dbmwU5yIXztYREoH36Zqncx4YqRbD4pfW5AoOhWfyC2gmVVQ== X-Received: by 2002:aca:5e84:0:b0:2ec:9c1d:fc77 with SMTP id s126-20020aca5e84000000b002ec9c1dfc77mr2388106oib.291.1652275033505; Wed, 11 May 2022 06:17:13 -0700 (PDT) Received: from ?IPV6:2804:431:c7ca:5fbd:9d46:f0f6:e4b6:b83b? ([2804:431:c7ca:5fbd:9d46:f0f6:e4b6:b83b]) by smtp.gmail.com with ESMTPSA id o19-20020a056870969300b000e686d13879sm160194oaq.19.2022.05.11.06.17.12 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 11 May 2022 06:17:12 -0700 (PDT) Message-ID: <03ae7107-605f-fe95-4594-cb7fbbe9ecf9@linaro.org> Date: Wed, 11 May 2022 10:17:10 -0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH v3 00/13] GLIBC LoongArch PATCHES Content-Language: en-US To: libc-alpha@sourceware.org References: <20220509022611.1248063-1-caiyinyu@loongson.cn> <8735hhb2m9.fsf@oldenburg.str.redhat.com> From: Adhemerval Zanella In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-5.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 11 May 2022 13:17:16 -0000 On 11/05/2022 03:57, Arnd Bergmann wrote: > On Tue, May 10, 2022 at 9:37 PM Florian Weimer via Libc-alpha > 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