Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 11 Apr 2022 11:40:03 +0800
From: 王洪亮 <>
Cc: Christian Brauner <>
Subject: Re: Re: add loongarch64 port

在 2022/4/9 下午7:06, Arnd Bergmann 写道:
> On Sat, Apr 9, 2022 at 5:55 AM 王洪亮 <> wrote:
>> 在 2022/4/8 下午2:46, Arnd Bergmann 写道:
>>> On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 <> wrote:
>>> 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

In clone3,the difference is move stack point's setup from userspace to 
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 
the stack's 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

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.