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
next prev parent 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).