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=-1.0 required=5.0 tests=HTML_MESSAGE, MAILING_LIST_MULTI,RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 16056 invoked from network); 7 Nov 2022 02:07:54 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 7 Nov 2022 02:07:54 -0000 Received: (qmail 24532 invoked by uid 550); 7 Nov 2022 02:07:51 -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 24499 invoked from network); 7 Nov 2022 02:07:50 -0000 From: =?UTF-8?B?546L5rSq5Lqu?= To: musl@lists.openwall.com Message-ID: Date: Mon, 7 Nov 2022 10:07:34 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------4ADF69887125D8F26994A8D4" Content-Language: en-US X-CM-TRANSID:AQAAf8Cx5VZmaGhjTDwOAA--.21331S3 X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ X-Coremail-Antispam: 1Uk129KBjvJXoWxAFW5KrW8uw4DWFWkZw47Jwb_yoW5WryfpF 1rZrsrGryrXrn5JrW8tF1kWFy8Jr48Xw4UJr18XFWUtr17Gw1jqr4UXayq9F17Xr4kAr4U ZF17XFy0vrsrAr7anT9S1TB71UUUUU7qnTZGkaVYY2UrUUUUj1kv1TuYvTs0mT0YCTnIWj DUYxn0WfASr-VFAUDa7-sFnT9fnUUIcSsGvfJTRUUUbz8YFVCjjxCrM7AC8VAFwI0_Jr0_ Gr1l1xkIjI8I6I8E6xAIw20EY4v20xvaj40_Wr0E3s1l1IIY67AEw4v_Jr0_Jr4l8cAvFV AK0II2c7xJM28CjxkF64kEwVA0rcxSw2x7M28EF7xvwVC0I7IYx2IY67AKxVWUCVW8JwA2 z4x0Y4vE2Ix0cI8IcVCY1x0267AKxVWUJVW8JwA2z4x0Y4vEx4A2jsIE14v26F4j6r4UJw A2z4x0Y4vEx4A2jsIEc7CjxVAFwI0_Gr0_Gr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l 57IF6xkI12xvs2x26I8E6xACxx1lYx0E2Ix0cI8IcVAFwI0_Jr0_Jr4lYx0Ex4A2jsIE14 v26r1j6r4UMcvjeVCFs4IE7xkEbVWUJVW8JwACjcxG0xvEwIxGrwCYjI0SjxkI62AI1cAE 67vIY487MxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I8CrV AFwI0_JrI_JrWlx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUJVWUXwCI c40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x0267 AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_Jr0_JF4lIxAIcVC2z280aVAFwI0_Jr0_ Gr1lIxAIcVC2z280aVCY1x0267AKxVWUJVW8JbIYCTnIWIevJa73UjIFyTuYvjxUr38nUU UUU Subject: [musl] A question about the __clone() within __NR_clone3 syscall in LoongArch. This is a multi-part message in MIME format. --------------4ADF69887125D8F26994A8D4 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Rich I found theclone3_stack_valid() in latest kernel, the condition of  (kargs->stack_size == 0) is still valid, so the __clone() (within __NR_clone3 syscall ) is still fail. we still implement __clone() within __NR_clone3 syscall in LoongArch ? diff --git a/src/thread/loongarch64/clone.s b/src/thread/loongarch64/clone.s new file mode 100644 index 00000000..86e69cfa --- /dev/null +++ b/src/thread/loongarch64/clone.s @@ -0,0 +1,47 @@ +#__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, 3, 0  # align stack to 16 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 +    jr    $ra            # 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 Do we still want to implement clone functionality entirely with clone3, given the previous conclusion of keeping clone(2) for existing sandboxes to continue to work? --------------4ADF69887125D8F26994A8D4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit

Hi, Rich

I found the clone3_stack_valid() in latest kernel,  the condition of  (kargs->stack_size == 0) is still valid,

so the __clone() (within __NR_clone3 syscall ) is still fail.

we still implement __clone() within __NR_clone3 syscall in LoongArch ?


diff --git a/src/thread/loongarch64/clone.s b/src/thread/loongarch64/clone.s
new file mode 100644
index 00000000..86e69cfa
--- /dev/null
+++ b/src/thread/loongarch64/clone.s
@@ -0,0 +1,47 @@
+#__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, 3, 0  # align stack to 16 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
+    jr    $ra            # 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

Do we still want to implement clone functionality entirely with clone3, given the
previous conclusion of keeping clone(2) for existing sandboxes to continue to work?

--------------4ADF69887125D8F26994A8D4--