[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Apr 2022 11:40:03 +0800
From: 王洪亮 <wanghongliang@...ngson.cn>
To: musl@...ts.openwall.com
Cc: Christian Brauner <brauner@...nel.org>
Subject: Re: Re: add loongarch64 port
在 2022/4/9 下午7:06, Arnd Bergmann 写道:
> On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <wanghongliang@...ngson.cn> wrote:
>> 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
>>> On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <wanghongliang@...ngson.cn> wrote:
>>>
>>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
>>>
>>> What happens in the clone() syscall in the kernel is that the size
>>> gets added to the initial pointer on normal architectures (parisc and ia64
>>> being the exceptions). If you already have the stack pointer, I think you can
>>> just pass size=0 as we do internally in the kernel.
>>>
>>> If there was a port of musl to one of the architectures that does it
>>> differently,
>>> then changing callers such as
>>>
>>> pid = __clone(child, stack+sizeof stack,
>>> CLONE_VM|CLONE_VFORK|SIGCHLD, &args);
>>>
>>> would be required, and the separate size argument in clone3() could
>>> help keep that hidden from musl.
>>>
>>> Arnd
>>
>> In LoongArch,the stack is grows down.
>>
>> As previous suggested,I implement __NR_clone3 syscall within __clone()
>> in loongarch port,based on __clone() interface unchanged and the
>> architecture-independent code of call __clone() unchanged.
>>
>> In __NR_clone3 syscall,I need pass the lowest address of memory area to
>> clone_args.stack,and pass stack_size to clone_args.stack_size(stack_size
>> must not be 0)
>> if (kargs->stack_size == 0)
>> return false;
>>
>> current,the __clone()'s input parameters have no "stack_size",so I can't
>> pass valid(must be size!=0) stack_size to clone3.
>>
>> your meaning is pass stack_size=0 when the input parameter "stack" of
>> __clone()
>> is already stack point? but pass stack_size=0 is illegal.
> Ah, you are right, that doesn't work at the moment. You dropped Christian
> from the Cc list, adding him back because he probably has an idea
> for how to address that.
>
> It looks like it could be fixed for the internal callers of __clone() by
> adding a __clone3() call that takes the size argument, and falls back
> to calling __clone() on architectures that have that. I don't see how
> one would do it for the generic clone() library function call though.
>
> Arnd
from Christian Brauner's patch in
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=fa729c4df5589
In clone3,the difference is move stack point's setup from userspace to
kernelspace.
userspace is only responsible for alloc memory area and pass the base
address of
memory area,kernel is responsible for setup stack point according to the
direction
the stack's grow.in other words,there is no longer the concept of stack
in userspace.
so clone3 is incompatible with clone.__NR_clone could not be removed
from kernel easily,
otherwise the existing user application call clone() is not work.
I understand the case is:
1.In kernel,__NR_clone and __NR_clone3 both support,at least for some time;
2.In libc,__clone() and __clone3() both implement(internal call,glibc
implement the convert),
clone() and clone3() both export for user.
3.existing application call clone() could work well, new application
could select to call
clone3().
Hongliang Wang
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
