mailing list of musl libc
 help / color / mirror / code / Atom feed
From: 王洪亮 <wanghongliang@loongson.cn>
To: musl@lists.openwall.com
Cc: Christian Brauner <brauner@kernel.org>
Subject: Re: [musl] Re: add loongarch64 port
Date: Thu, 21 Apr 2022 14:54:30 +0800	[thread overview]
Message-ID: <deee6a58-3745-420a-91c6-f58fe728a27c@loongson.cn> (raw)
In-Reply-To: <20220420135449.GC7074@brightrain.aerifal.cx>


在 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


  reply	other threads:[~2022-04-21  6:54 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-31  6:20 王洪亮
2022-03-31  8:14 ` Arnd Bergmann
2022-04-01  7:40   ` 王洪亮
2022-04-01  7:48     ` Arnd Bergmann
2022-04-02  6:19       ` 王洪亮
2022-04-02  7:21         ` Rich Felker
2022-04-02  9:53           ` 王洪亮
2022-04-27  1:58   ` 王洪亮
2022-04-27  2:13     ` Rich Felker
2022-03-31 18:47 ` Rich Felker
2022-04-02  7:59   ` 王洪亮
2022-04-06  2:08     ` 王洪亮
2022-04-06 16:00       ` Markus Wichmann
2022-04-08  2:21         ` 王洪亮
2022-04-08  6:46           ` Arnd Bergmann
2022-04-09  3:54             ` 王洪亮
2022-04-09 11:06               ` Arnd Bergmann
2022-04-09 13:19                 ` Rich Felker
2022-04-09 13:30                   ` Rich Felker
2022-04-10 10:30                     ` Arnd Bergmann
2022-04-10 15:26                       ` Rich Felker
2022-04-11  8:03                         ` Arnd Bergmann
2022-04-11 12:11                           ` Rich Felker
2022-04-11 13:01                             ` Arnd Bergmann
2022-04-12  1:11                               ` 王洪亮
2022-04-13  1:16                                 ` 王洪亮
2022-04-13  7:26                       ` Christian Brauner
2022-04-13  8:26                         ` Arnd Bergmann
2022-04-13  9:04                           ` Christian Brauner
2022-04-13 13:25                             ` Arnd Bergmann
2022-04-13 14:09                               ` Rich Felker
2022-04-14  9:36                                 ` Christian Brauner
2022-04-20  9:09                                   ` 王洪亮
2022-04-20 13:33                                     ` Christian Brauner
2022-04-20 13:54                                       ` Rich Felker
2022-04-21  6:54                                         ` 王洪亮 [this message]
2022-04-14  9:36                               ` Christian Brauner
2022-04-13  7:19                   ` Christian Brauner
2022-04-13 14:06                     ` Rich Felker
2022-04-11  3:40                 ` 王洪亮
  -- strict thread matches above, loose matches on Subject: below --
2022-03-22  3:52 [musl] " 王洪亮
2022-03-29  8:12 ` [musl] " 王洪亮
2022-03-29  8:26   ` Arnd Bergmann

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=deee6a58-3745-420a-91c6-f58fe728a27c@loongson.cn \
    --to=wanghongliang@loongson.cn \
    --cc=brauner@kernel.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).