From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26121 invoked from network); 13 Apr 2022 08:26:40 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 13 Apr 2022 08:26:40 -0000 Received: (qmail 31818 invoked by uid 550); 13 Apr 2022 08:26:38 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31780 invoked from network); 13 Apr 2022 08:26:37 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649838384; bh=8EjZiFQD4J9T+0YPCb0DR6VvO5RWlVHK+9svFjLOIuk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=OSqiKaQpB1WwUBJfTQy2VBuP/qDhEXBS+kxmRE9LNzR9ufEP1USKzOM4ty4f5yOc1 QCjSRZAhPgHw1g+gmyXAsLlIpE5bujMoYrWqNMWneiE5nbN0LBHx3dFU/iHl/mDlb5 fiPjQ8YtTJ0XayqThQDx/T5d76+lkl9mXHvrqDgw6UokPiwKpEDZdN5Prc97OpatER p62/+A0Oc/rDFiW8XdhaSa7wZoZO7FTuDKTHcaqJpuZpLxAYVNJ72QMCt8KdxQoYk0 8eyW6NBiIObD3Sq1z23mEpjE+aGqzF1JN0mK3cxTJhhBRS8Le03y1KTJvpx/bF5KAz jTkQjWUoxYSnw== X-Gm-Message-State: AOAM532F2vRBN2Outte/rciptnu/r6PiZF5Quz5x6ekU2OBPU1+efmKP 1iR3pVcAMNg3lWRsF8o3oh8vbs1KOo0fxTq9AGo= X-Google-Smtp-Source: ABdhPJx2KTH4GHTjes9kiRpb0KCFglmrvI1trWaN/kUS1Jj2Ne7q4f14ckdgYmPVv9RkPYpQ3lkluo8lSXq6lJn7GCU= X-Received: by 2002:a05:6000:1561:b0:207:adbb:d33b with SMTP id 1-20020a056000156100b00207adbbd33bmr5494387wrz.317.1649838383035; Wed, 13 Apr 2022 01:26:23 -0700 (PDT) MIME-Version: 1.0 References: <1fec7c01-ea91-aa7c-d6d5-474c00d9347c@loongson.cn> <20220406160042.GB8499@voyager> <8dfcd620-4143-7450-8429-a89ed2264620@loongson.cn> <20220409131939.GK7074@brightrain.aerifal.cx> <20220409133044.GL7074@brightrain.aerifal.cx> <20220413072606.44wwkk64xshn5mmm@wittgenstein> In-Reply-To: <20220413072606.44wwkk64xshn5mmm@wittgenstein> From: Arnd Bergmann Date: Wed, 13 Apr 2022 10:26:06 +0200 X-Gmail-Original-Message-ID: Message-ID: To: Christian Brauner Cc: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Subject: Re: [musl] Re: add loongarch64 port On Wed, Apr 13, 2022 at 9:26 AM Christian Brauner wrote: > On Sun, Apr 10, 2022 at 12:30:59PM +0200, Arnd Bergmann wrote: > > On Sat, Apr 9, 2022 at 3:31 PM Rich Felker wrote: > > > > > > Actually, if there aren't yet archs lacking SYS_clone, this API > > > regression may be a good argument not to drop SYS_clone on new archs > > > yet until there's a way for new archs to get the same behavior > > > (unspecified stack size). > > > > That is a good point, but it also appears that the behavior of > > clone3() is unintentional > > here, I'm fairly sure it was meant to be a drop-in replacement for clone() with > > additional features. > > Mostly but not in all ways. We did decide it's ok to make API > improvements that might break compatibility with legacy clone(). Ok > > > > Not sure what the best fix for this is, as the check for size==0 was clearly > > intentional, but seems to prevent this from working. A special flag to ignore > > the size, or a magic size value like -1ull might work, but neither of them > > is a great interface. > > Can someone explain the use-case in a bit more detail, please? > > If it is a legitimate use-case that callers need to be able to pass a > stack and have no way of also passing a size then we should just remove > the size == 0 check for all architectures that don't have a hard > requirement on passing a size together with the stack pointer. > > Wdyt, Arnd? The normal rule is that we don't define obsolete system calls in new architectures when an improved variant has been added, e.g. oldoldstat, oldstat, stat, newstat and stat64 have all been replaced by statx over the decades. I was expecting the same to be true for clone(), but if clone3() is not meant as a replacement, we can keep both around. Arnd