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=-3.3 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 5123 invoked from network); 9 Apr 2022 03:55:14 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Apr 2022 03:55:14 -0000 Received: (qmail 24525 invoked by uid 550); 9 Apr 2022 03:55:11 -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 24489 invoked from network); 9 Apr 2022 03:55:10 -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> From: =?UTF-8?B?546L5rSq5Lqu?= Message-ID: Date: Sat, 9 Apr 2022 11:54:56 +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:AQAAf9DxPxCQA1Fiwu4bAA--.5117S3 X-Coremail-Antispam: 1UD129KBjvJXoWxZF17tr18tr1fCrW8Zw18Xwb_yoW5CFy3pF WvkF4Ikrs8JrWSgryIvw18GFy2yws5Jw1j9ryrJ34UAr90qr1Svr4Ut34Ygr47Cw1vkw4j qa1YqwnrZw1DA3DanT9S1TB71UUUUUUqnTZGkaVYY2UrUUUUjbIjqfuFe4nvWSU5nxnvy2 9KBjDU0xBIdaVrnRJUUUv2b7Iv0xC_tr1lb4IE77IF4wAFF20E14v26r1j6r4UM7CY07I2 0VC2zVCF04k26cxKx2IYs7xG6rWj6s0DM7CIcVAFz4kK6r1j6r18M28lY4IEw2IIxxk0rw A2F7IY1VAKz4vEj48ve4kI8wA2z4x0Y4vE2Ix0cI8IcVAFwI0_Gr0_Xr1l84ACjcxK6xII jxv20xvEc7CjxVAFwI0_Gr0_Cr1l84ACjcxK6I8E87Iv67AKxVW8Jr0_Cr1UM28EF7xvwV C2z280aVCY1x0267AKxVW8Jr0_Cr1UM2AIxVAIcxkEcVAq07x20xvEncxIr21l5I8CrVAC Y4xI64kE6c02F40Ex7xfMcIj6xIIjxv20xvE14v26r1j6r18McIj6I8E87Iv67AKxVWUJV W8JwAm72CE4IkC6x0Yz7v_Jr0_Gr1lF7xvr2IY64vIr41lc7I2V7IY0VAS07AlzVAYIcxG 8wCY02Avz4vE-syl42xK82IYc2Ij64vIr41l4I8I3I0E4IkC6x0Yz7v_Jr0_Gr1lx2IqxV Aqx4xG67AKxVWUJVWUGwC20s026x8GjcxK67AKxVWUGVWUWwC2zVAF1VAY17CE14v26r1j 6r15MIIYrxkI7VAKI48JMIIF0xvE2Ix0cI8IcVAFwI0_Jr0_JF4lIxAIcVC0I7IYx2IY6x kF7I0E14v26r1j6r4UMIIF0xvE42xK8VAvwI8IcIk0rVWrZr1j6s0DMIIF0xvEx4A2jsIE 14v26r1j6r4UMIIF0xvEx4A2jsIEc7CjxVAFwI0_Jr0_GrUvcSsGvfC2KfnxnUUI43ZEXa 7IU8v_M3UUUUU== X-CM-SenderInfo: pzdqwxxrqjzxhdqjqz5rrqw2lrqou0/ Subject: Re: [musl] Re: add loongarch64 port 在 2022/4/8 下午2:46, Arnd Bergmann 写道: > On Fri, Apr 8, 2022 at 4:21 AM 王洪亮 wrote: >> 在 2022/4/7 上午12:00, Markus Wichmann 写道: >>> On Wed, Apr 06, 2022 at 10:08:24AM +0800, 王洪亮 wrote: >>>> Hi, Rich >>>> >>>> >>>> within __clone() implement __NR_clone3 syscall, >>>> >>>> will that confusion between clone and clone3? >>>> >>>> >>>> Hongliang Wang >>>> >>>> >>>> >>> __clone() is a function with a defined interface. How it is implemented >>> is not given in the name. Why should __clone() have to be implemented >>> using the SYS_clone system call? If I understood the thread so far >>> correctly, the final kernel will not even have SYS_clone. >>> >>> Compare with open(), which is often implemented in terms of SYS_openat >>> instead of SYS_open. Or qsort(), which, despite the name, is rarely >>> implemented as a quicksort. >>> >>> So no, there will be no confusion of system calls because a function is >>> not implemented in terms of the system call of the same name, as long as >>> the function fulfills the defined interface. >>> >>> Ciao, >>> Markus >> Hi, >> >> I agree this point. >> In the implementation,I found a problem: >> In order to implement __NR_clone3 syscall in __clone(), >> I need to fill struct clone_args,I found clone_args.stack >> point to the lowest address of stack,but the input parameter >> "stack" of __clone() point to stack bottom(STACK_GROWS_DOWN), >> because of no stack_size,I can't convert between them. >> Do you have any good suggestions? > There is a good explanation from Christian Brauner about this in > > 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. Hongliang Wang