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=-5.8 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,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 7688 invoked from network); 20 Apr 2022 09:10:26 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2022 09:10:26 -0000 Received: (qmail 3985 invoked by uid 550); 20 Apr 2022 09:09:34 -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 3919 invoked from network); 20 Apr 2022 09:09:33 -0000 To: musl@lists.openwall.com, Christian Brauner References: <20220409131939.GK7074@brightrain.aerifal.cx> <20220409133044.GL7074@brightrain.aerifal.cx> <20220413072606.44wwkk64xshn5mmm@wittgenstein> <20220413090425.rmprwzpgpztianin@wittgenstein> <20220413140930.GV7074@brightrain.aerifal.cx> <20220414093624.57kdl26xro6vbap4@wittgenstein> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: Date: Wed, 20 Apr 2022 17:09:08 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <20220414093624.57kdl26xro6vbap4@wittgenstein> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf9Dx39e0zV9i+dwpAA--.24566S3 X-Coremail-Antispam: 1UD129KBjvJXoWxWFyrur15CFWUGw1UXF45GFg_yoW5Ww43pF y0yF4jvryFyr18XrW2qw1UZry8tw4UXw4jvr98Ga4UAF15Jr1Fqr18XayY9F45JrW8KF1j qF17tF1Ivw4DAaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr1j6F4UJwA2z4x0Y4vEx4A2jsIE14v26rxl6s0DM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l c2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWU AwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AK xVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07 bOoGdUUUUU= X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] Re: add loongarch64 port 在 2022/4/14 下午5:36, Christian Brauner 写道: > On Wed, Apr 13, 2022 at 10:09:31AM -0400, Rich Felker wrote: >> On Wed, Apr 13, 2022 at 03:25:05PM +0200, Arnd Bergmann wrote: >>> On Wed, Apr 13, 2022 at 11:04 AM Christian Brauner wrote: >>>> On Wed, Apr 13, 2022 at 10:26:06AM +0200, Arnd Bergmann wrote: >>>>> 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. >>>> No, I agree with you on this and would like to only implement clone3() >>>> on new architectures. >>>> >>>> What I'm asking is whether removing the size == 0 check is enough to >>>> unblock the missing behavior and whether you'd be on board with removing >>>> the check? >>> I think that's ok here, since we'd only rely on this for loongarch64 at the >>> moment. It would probably need to be documented in the man page >>> as a special case though. >> I'm okay with removing the check for size==0 (so size==0 will be >> allowed) and dropping __NR_clone on new archs, as long as it's noted >> in comments/documentation that size==0 is explicitly allowed so nobody >> breaks this in the future. > Ok, I'll try to have a patch ready early next week since I'm currently > out sick. Hi, I'm implementing  __NR_clone3 syscall within __clone(). I have another problem:CLONE_DETACHED in musl,internal call __clone()(such as __pthread_create()),the input parameter flags has been set CLONE_DETACHED ,in kernel,there is a check in clone3_args_valid(), if the condition met,return false. How to deal with this problem? src/thread/pthread_create.c: int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict attrp,                                 void *(*entry)(void *), void *restrict arg) {     unsigned flags = CLONE_VM | CLONE_FS | CLONE_FILES | CLONE_SIGHAND     | CLONE_THREAD | CLONE_SYSVSEM | CLONE_SETTLS     | CLONE_PARENT_SETTID | CLONE_CHILD_CLEARTID | CLONE_DETACHED;     ...     ret = __clone((c11 ? start_c11 : start), stack, flags, args, &new->tid,                             TP_ADJ(new), &__thread_list_lock); } kernel/fork.c: static bool clone3_args_valid(struct kernel_clone_args *kargs) {          /*           * - make the CLONE_DETACHED bit reusable for clone3           * - make the CSIGNAL bits reusable for clone3           */          if (kargs->flags & (CLONE_DETACHED | CSIGNAL))                  return false; } Hongliang Wang