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 6779 invoked from network); 21 Apr 2022 06:54:47 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 21 Apr 2022 06:54:47 -0000 Received: (qmail 23796 invoked by uid 550); 21 Apr 2022 06:54:45 -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 23755 invoked from network); 21 Apr 2022 06:54:44 -0000 To: musl@lists.openwall.com References: <20220409133044.GL7074@brightrain.aerifal.cx> <20220413072606.44wwkk64xshn5mmm@wittgenstein> <20220413090425.rmprwzpgpztianin@wittgenstein> <20220413140930.GV7074@brightrain.aerifal.cx> <20220414093624.57kdl26xro6vbap4@wittgenstein> <20220420133325.pdppfuc3ijggrgc4@wittgenstein> <20220420135449.GC7074@brightrain.aerifal.cx> Cc: Christian Brauner From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: Date: Thu, 21 Apr 2022 14:54:30 +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: <20220420135449.GC7074@brightrain.aerifal.cx> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf9Dx3xOm_2BiAesqAA--.26037S3 X-Coremail-Antispam: 1UD129KBjvJXoWxXF4fGw47ur4rtF1xXry5Arb_yoWrZrWfpF 18AF4UJryUAr18Jry8tr18GryUJr18Jw4UJr15JFWUtry5Cr1jqr1UXryj9F13Jr4kJr4U Zr17Jr1UZF4DArJanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_Kw4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Xr0_Ar1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV 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/20 下午9:54, Rich Felker 写道 >>> 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.) > I think __clone should just mask it on newer archs. We support Linux > 2.6.0 and if lack of CLONE_DETACHED causes bogus signals on 2.6.0 we > should keep it. If it can be established that this doesn't happen and > that CLONE_DETACHED just affected non-thread clones, we can probably > safely drop it. > > Rich I have already implemented __NR_clone3 syscall within __clone(), and libc-test OK.the code is shown below,please help review. src/thread/loongarch64/clone.s: #__clone(func, stack, flags, arg, ptid, tls, ctid) #         a0,    a1,   a2,    a3,  a4,  a5,   a6 # sys_clone3(struct clone_args *cl_args, size_t size) #                                 a0             a1 .global __clone .hidden __clone .type   __clone,@function __clone:         # Save function pointer and argument pointer on new thread stack         addi.d  $a1, $a1, -16         st.d    $a0, $a1, 0     # save function pointer         st.d    $a3, $a1, 8     # save argument pointer         li.d    $t0, ~0x004000ff  # mask CSIGNAL and CLONE_DETACHED         and     $t1, $a2, $t0     # cl_args.flags         li.d    $t0, 0x000000ff   # CSIGNAL         and     $t2, $a2, $t0     # cl_args.exit_signal         bstrins.d $sp, $zero, 2, 0  # align stack to 8 bytes         addi.d  $sp, $sp, -88   # struct clone_args         st.d    $t1, $sp, 0     # flags         st.d    $a4, $sp, 8     # pidfd         st.d    $a6, $sp, 16    # child_tid         st.d    $a4, $sp, 24    # parent_tid         st.d    $t2, $sp, 32    # exit_signal         st.d    $a1, $sp, 40    # stack         st.d    $zero, $sp, 48  # stack_size         st.d    $a5, $sp, 56    # tls         st.d    $zero, $sp, 64  # set_tid         st.d    $zero, $sp, 72  # set_tid_size         st.d    $zero, $sp, 80  # cgroup         move    $a0, $sp         li.d    $a1, 88         li.d    $a7, 435        # __NR_clone3         syscall 0               # call clone3         beqz    $a0, 1f         # whether child process         addi.d  $sp, $sp, 88         jirl    $zero, $ra, 0   # parent process return 1:         ld.d    $t8, $sp, 0     # function pointer         ld.d    $a0, $sp, 8     # argument pointer         jirl    $ra, $t8, 0     # call the user's function         li.d    $a7, 93         syscall 0               # child process exit