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=-4.0 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 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 8091 invoked from network); 20 Apr 2022 13:33:44 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 Apr 2022 13:33:44 -0000 Received: (qmail 8146 invoked by uid 550); 20 Apr 2022 13:33:41 -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 8108 invoked from network); 20 Apr 2022 13:33:41 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1650461608; bh=G2m4NHEqhW9Fv7allfyaff2pk8JSLwdE0Y88k/dIj9U=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mVQHJoZR2Zo8obVzKTbZyBvG145GIPjdAjJj88kfZnKhV5yYLS7g1hsexEoFq55uS 3aVSN2D8su1zqPeO1C/Ay35EQZ0GSn5PvOF9N8RvcnBImKITPIlVqFOVVc8F/Z6dKa 6jL7+N+M4gy+NLryMUgp1jMcnYJPWoDRnXhjjZ43dGJ4//Nmt1vk+D9u0PLjP39vjw UkxyXpls4HWv/P3qJQfOMZ31rpSX8xa+YU947OI8B4Yr43GGv0g95J+lOfMw3eW6FE LFTdNILNxonJVH3FBxhbaWNx3yM2H8owY8TioK4N3iCIM5ddwfPBAHhTcETiOQve0s j0PFYY0rVMLHg== Date: Wed, 20 Apr 2022 15:33:25 +0200 From: Christian Brauner To: =?utf-8?B?546L5rSq5Lqu?= Cc: musl@lists.openwall.com Message-ID: <20220420133325.pdppfuc3ijggrgc4@wittgenstein> 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> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: Subject: Re: [musl] Re: add loongarch64 port On Wed, Apr 20, 2022 at 05:09:08PM +0800, 王洪亮 wrote: > > 在 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? CLONE_DETACHED is meaningles since Linux on 2.6.2. There really should be <=2.6.1 living kernel anywhere where CLONE_DETACHED does anything. I've documented that in detail under [1] as: CLONE_DETACHED (historical) For a while (during the Linux 2.5 development series) there was a CLONE_DETACHED flag, which caused the parent not to receive a signal when the child terminated. Ultimately, the effect of this flag was subsumed under the CLONE_THREAD flag and by the time Linux 2.6.0 was released, this flag had no effect. Starting in Linux 2.6.2, the need to give this flag together with CLONE_THREAD disappeared. This flag is still defined, but it is usually ignored when calling clone(). However, see the description of CLONE_PIDFD for some exceptions. [1]: https://man7.org/linux/man-pages/man2/clone.2.html Would it be possible to drop this flag from musl's pthread_create() implementation? (Iirc, glibc dropped CLONE_DETACHED in 2004.) > > 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 >