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, 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 16022 invoked from network); 12 May 2022 07:21:46 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 12 May 2022 07:21:46 -0000 Received: (qmail 17466 invoked by uid 550); 12 May 2022 07:21: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 17431 invoked from network); 12 May 2022 07:21:43 -0000 X-Gm-Message-State: AOAM5300tD77JCmnJdydFtjqpl7NJx0j2/MlJtpJBi+zUWP1oJefQGew 1bdkxGZG/5c2uIAPD2aMdOVvKpewAeBm/SaM2SU= X-Google-Smtp-Source: ABdhPJx4WfEOUWv2L6bCmWT0mJB6dEDWkNIHboRAE66MHFC+PuQA7c4QPgkOpP2BhGDSQSBJfhNNN89Hg26ByytWHec= X-Received: by 2002:a25:cdc7:0:b0:648:f57d:c0ed with SMTP id d190-20020a25cdc7000000b00648f57dc0edmr26571261ybf.480.1652340090303; Thu, 12 May 2022 00:21:30 -0700 (PDT) MIME-Version: 1.0 References: <20220430090518.3127980-1-chenhuacai@loongson.cn> <20220430090518.3127980-14-chenhuacai@loongson.cn> <20220507121104.7soocpgoqkvwv3gc@wittgenstein> <20220509100058.vmrgn5fkk3ayt63v@wittgenstein> <20220511211231.GG7074@brightrain.aerifal.cx> In-Reply-To: <20220511211231.GG7074@brightrain.aerifal.cx> From: Arnd Bergmann Date: Thu, 12 May 2022 09:21:13 +0200 X-Gmail-Original-Message-ID: Message-ID: To: musl@lists.openwall.com Cc: Arnd Bergmann , Christian Brauner , Huacai Chen , Huacai Chen , Andy Lutomirski , Thomas Gleixner , Peter Zijlstra , Andrew Morton , David Airlie , Jonathan Corbet , Linus Torvalds , linux-arch , "open list:DOCUMENTATION" , Linux Kernel Mailing List , Xuefeng Li , Yanteng Si , Guo Ren , Xuerui Wang , Jiaxun Yang , Linux API , GNU C Library Content-Type: text/plain; charset="UTF-8" X-Provags-ID: V03:K1:kasv95MMLlrQMegX8FijNPNWaX1vcBJwZEroev3kB39X0ehCjrE NxMV16LRG8Fg1bQLHw+e4/vK9XGB6XSQ9cfwcXtTh6l6QmkIOntXvC3pU3L/Mk9QVZdjloS XbbJQh9r6iApLCF5LrvpWAN/nZoFlFXaxM16ytmzX3r0Bf5xgy7a8b5ZQflwrs4SSl0fVuX 9JOjmI58UWyGQCwjwVcYA== X-UI-Out-Filterresults: notjunk:1;V03:K0:DGj5Ctnqk14=:WVwCfMg7bjUSTmS256ywxo Ox0E7e932mAgwwVRcgim48KF6R9f+tsNhTAZWcRMSUAwBhQQqKP3OzpXdVVgYB3DvINF6m3l6 ihcaQ7jkys3omotjba7mpxrKEYfIMozajKLetdl2B9gYEY6F4eWe+UHg2ao00SrbY030rtge5 YwdNU3wJ+zaxSvVe+iJGv1rjuaKMTKWCijiX5xKxfxXe4eImZgFZPXxaltkafQUPriGT3uLSU Djnf9TInaATDTjtjvF3o5FHwO45B2odGWAb8Gph5jSyQ9yRSmfJmyBqZtDcIi8WV5YeM/FLjO iDoEYdmxLhZS/pT0MYa6l5UfEOybI1U919j89yLJA7E9Q5270yv1a7nfy1ZGy/WRrcEK9jI7l Wh4MQiEF5s86djboovGtG7YPyrmnw3zjFQG1+TyIYC6PqBt/C09P4ESl/SLbvZndc5cOHdzVF QovAwaA4lpAbKxZPHO7evBlKTWO9kmwCIgzxiXGq7ZJA2WezEDVMAz5S36lPt1nZ5hGHqSdgH IfRpaCEdpYeQp+oCzBGGkOPM2C7U3bJMK0ov+FfznNXgVqC4oa9DzkDmEq44Mv96Dqyq8Umo/ oGShRs8T/sNwCtjT81IgpbpwjufO6culXEhxpWXyUc93FAT+nTKx/yiAkTHpOS0f6cO2U8//E I43V9mSycmYmv1qgadlq8B1rg6eoi4PzbXos9Bsjm5Af13ntF5kVekwNNe5IC9JM0ExjvqiRr nAD2RmWu777DotZ5TYAR4wEEM/i5/UEK4ytoRcqCf/4O2VkPz4TbZ1mZ9Z3aQv46vEg8Mmmr4 GKsPAY3x8ld5sBaJW/AdNhpewkFgPtgHIZkhkWrMgrW+EULM0WTKNrXrDpLqRpldVMnCMPp93 dgVeW2yb4hV66bGH8AiXnX1TDLCXkkgb/hl/aSLT8= Subject: Re: [musl] Re: [PATCH V9 13/24] LoongArch: Add system call support On Wed, May 11, 2022 at 11:12 PM Rich Felker wrote: > On Wed, May 11, 2022 at 09:11:56AM +0200, Arnd Bergmann wrote: > > On Mon, May 9, 2022 at 12:00 PM Christian Brauner wrote: > > ..... > > > I can try and move a poc for this up the todo list. > > > > > > Without an approach like this certain sandboxes will fallback to > > > ENOSYSing system calls they can't filter. This is a generic problem > > > though with clone3() being one promiment example. > > > > Thank you for the detailed reply. It sounds to me like this will eventually have > > to get solved anyway, so we could move ahead without clone() on loongarch, > > and just not have support for Chrome until this is fully solved. > > > > As both the glibc and musl ports are being proposed for inclusion right > > now, we should try to come to a decision so the libc ports can adjust if > > necessary. Adding both mailing lists to Cc here, the discussion is archived > > at [1]. > > > > Arnd > > > > [1] https://lore.kernel.org/linux-arch/20220509100058.vmrgn5fkk3ayt63v@wittgenstein/ > > Having read about the seccomp issue, I think it's a very strong > argument that __NR_clone should be kept permanently for all future > archs. Ok, let's keep clone() around for all architectures then. We should probably just remove the __ARCH_WANT_SYS_CLONE macro and build the code into the kernel unconditionally, but at the moment there are still private versions for ia64 and sparc with the same name as the generic version. Both are also still lacking support for clone3() and don't have anyone actively working on them. In this case, we probably don't need to change clone3() to allow the zero-length stack after all, and the wrapper that was added to the musl port should get removed again. For the other syscalls, I think the latest musl patches already dropped the old-style stat() implementation, but the glibc patches still have those and need to drop them as well to match what the kernel will get. Arnd