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=-5.8 required=5.0 tests=MAILING_LIST_MULTI, NICE_REPLY_A,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 24831 invoked from network); 11 Apr 2022 03:40:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 11 Apr 2022 03:40:21 -0000 Received: (qmail 16175 invoked by uid 550); 11 Apr 2022 03:40:18 -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 16128 invoked from network); 11 Apr 2022 03:40:17 -0000 To: musl@lists.openwall.com References: <64c0ef49-4618-8eca-c826-bd2a840c284b@loongson.cn> <20220331184719.GH7074@brightrain.aerifal.cx> <1fec7c01-ea91-aa7c-d6d5-474c00d9347c@loongson.cn> <20220406160042.GB8499@voyager> <8dfcd620-4143-7450-8429-a89ed2264620@loongson.cn> Cc: Christian Brauner From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: Date: Mon, 11 Apr 2022 11:40:03 +0800 User-Agent: Mozilla/5.0 (X11; Linux mips64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-CM-TRANSID:AQAAf9Dxv9cTo1NiTm8eAA--.8293S3 X-Coremail-Antispam: 1UD129KBjvJXoWxZr45GrWkZr17tF1fGryfJFb_yoW5ur15pF ZI9F1IkFs8JrW7KrZ2vw10kFyakrs5Jr1akr95J345Cry5tF1fZr4UZayUuF47Cw1v9w4a qrs8XFnru3Z8ZaDanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUvYb7Iv0xC_KF4lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Ar0_tr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Cr0_Gr1UM28EF7xvwVC2z280aVAFwI0_Cr1j6rxdM28EF7xvwV C2z280aVCY1x0267AKxVW0oVCq3wAS0I0E0xvYzxvE52x082IY62kv0487Mc02F40EFcxC 0VAKzVAqx4xG6I80ewAv7VC0I7IYx2IY67AKxVWUJVWUGwAv7VC2z280aVAFwI0_Jr0_Gr 1lOx8S6xCaFVCjc4AY6r1j6r4UM4x0Y48IcVAKI48JMxk0xIA0c2IEe2xFo4CEbIxvr21l c2xSY4AK6svPMxAIw28IcxkI7VAKI48JMxC20s026xCaFVCjc4AY6r1j6r4UMI8I3I0E5I 8CrVAFwI0_Jr0_Jr4lx2IqxVCjr7xvwVAFwI0_JrI_JrWlx4CE17CEb7AF67AKxVWUXVWU AwCIc40Y0x0EwIxGrwCI42IY6xIIjxv20xvE14v26r1j6r1xMIIF0xvE2Ix0cI8IcVCY1x 0267AKxVWUJVW8JwCI42IY6xAIw20EY4v20xvaj40_WFyUJVCq3wCI42IY6I8E87Iv67AK xVWUJVW8JwCI42IY6I8E87Iv6xkF7I0E14v26r1j6r4UYxBIdaVFxhVjvjDU0xZFpf9x07 jOb18UUUUU= X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] 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: >>> >>> 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