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.4 required=5.0 tests=DKIMWL_WL_HIGH,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,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 30454 invoked from network); 9 Apr 2022 11:06:47 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 9 Apr 2022 11:06:47 -0000 Received: (qmail 5788 invoked by uid 550); 9 Apr 2022 11:06:44 -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 5756 invoked from network); 9 Apr 2022 11:06:43 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1649502390; bh=kJTb/AvAsfXiHslKgBIOOMSFiy6HjKOvZBrRX2S7N4U=; h=References:In-Reply-To:From:Date:Subject:To:From; b=BG28fbshyl1L7aM+sA5AaE4nciz5ZC1pUqvNKarrhPjkse8Q9sB4YPCJSGFpQMDAE xJauhIrks1Zt2fbfbCy2RLTZbmUjIHsRpo3RqsmZwNQYeEGi3A7gnSs/VfWNU/7dFC fzsigBuuH5X2WeE9vAybO0s/L6p8pk4Nnc9nMa9WiT8FDKFUCrw+l1IJIHkjFrT2NJ IwKcarxId/HTNstQQ78QgoDl8cstGylwNhlHJLM4S8z4tWXOeLiGss1rgAMeOle7/C qagtmY/K6YgLYWy71nEfqDFxd3qUIHwKKhSHaVkL/Ljm3XAHV2hEO/z9phbPFaMIqI IlbVez1XEBVow== X-Gm-Message-State: AOAM533RFZX60rnbAqLR85t3JYelESjh5gJSGBAPV9o+l2EICj2vHNXM C1pdUD4oa2S9uWysSIS/C0ceYlUQ6/o0OmVWZjk= X-Google-Smtp-Source: ABdhPJw52qHUhZpZrHilqW+fvD94AqB9rq/0mCZIsTNFusfxFJZP7kUWJGm4JQb2I+0c1vW4JR9S1+hqUOdwVE7FEz4= X-Received: by 2002:a05:6000:154d:b0:207:9101:8f24 with SMTP id 13-20020a056000154d00b0020791018f24mr6341867wry.317.1649502389118; Sat, 09 Apr 2022 04:06:29 -0700 (PDT) MIME-Version: 1.0 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> In-Reply-To: From: Arnd Bergmann Date: Sat, 9 Apr 2022 13:06:13 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com, Christian Brauner Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [musl] Re: add loongarch64 port On Sat, Apr 9, 2022 at 5:55 AM =E7=8E=8B=E6=B4=AA=E4=BA=AE wrote: > =E5=9C=A8 2022/4/8 =E4=B8=8B=E5=8D=882:46, Arnd Bergmann =E5=86=99=E9=81= =93: > > On Fri, Apr 8, 2022 at 4:21 AM =E7=8E=8B=E6=B4=AA=E4=BA=AE wrote: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/comm= it/?id=3Dfa729c4df5589 > > > > What happens in the clone() syscall in the kernel is that the size > > gets added to the initial pointer on normal architectures (parisc and i= a64 > > being the exceptions). If you already have the stack pointer, I think y= ou can > > just pass size=3D0 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 =3D __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 =3D=3D 0) > return false; > > current,the __clone()'s input parameters have no "stack_size",so I can't > pass valid(must be size!=3D0) stack_size to clone3. > > your meaning is pass stack_size=3D0 when the input parameter "stack" of > __clone() > is already stack point? but pass stack_size=3D0 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