From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id DF9C8C433F5 for ; Sat, 7 May 2022 12:11:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1392221AbiEGMPD (ORCPT ); Sat, 7 May 2022 08:15:03 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55818 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1391180AbiEGMPB (ORCPT ); Sat, 7 May 2022 08:15:01 -0400 Received: from ams.source.kernel.org (ams.source.kernel.org [145.40.68.75]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 0DD4033884; Sat, 7 May 2022 05:11:15 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id BAC15B8009F; Sat, 7 May 2022 12:11:13 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id CE1A7C385A6; Sat, 7 May 2022 12:11:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1651925472; bh=ny0hixdm2DB1RZtEMrHXgACsqdZeemYTQuhSsXAyMAQ=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=YW/RatCk8lNqeYJ1ojv5lru5Rw94pEIjaS0Hr8WaAXhjDPEQzKEk6OwQtyjRQKsqV X4vxkcKZItcNhYtEERfPTd2aVVu3bLMQpxtFgwGUbQeEkd8UZ7paOdYxod1Hv9RYBb 5L3QuWJ3nkLRvkUcX7RevWAz2F8UJXQT4zR6VTw535S6VaZbNHKDtESBkKNBVJoDQa iKHGcQOVxeCqWmNKWw0WDUoEI6Xh/vho/9QsUvlzDK2h8hUdmKtZhRo/jERXARmo/i 5A+aU9pxupmDFO7WigUACN918yMjoLFQvWHI8uWtc5Tk+Ns7xrcyApL5YPx4oxccB+ H1eFW5aaPCiFg== Date: Sat, 7 May 2022 14:11:04 +0200 From: Christian Brauner To: Arnd Bergmann Cc: 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 Subject: Re: [PATCH V9 13/24] LoongArch: Add system call support Message-ID: <20220507121104.7soocpgoqkvwv3gc@wittgenstein> References: <20220430090518.3127980-1-chenhuacai@loongson.cn> <20220430090518.3127980-14-chenhuacai@loongson.cn> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: Precedence: bulk List-ID: X-Mailing-List: linux-api@vger.kernel.org On Sat, Apr 30, 2022 at 12:34:52PM +0200, Arnd Bergmann wrote: > On Sat, Apr 30, 2022 at 12:05 PM Huacai Chen wrote: > > On Sat, Apr 30, 2022 at 5:45 PM Arnd Bergmann wrote: > > > On Sat, Apr 30, 2022 at 11:05 AM Huacai Chen wrote: > > > > > > > > This patch adds system call support and related uaccess.h for LoongArch. > > > > > > > > Q: Why keep __ARCH_WANT_NEW_STAT definition while there is statx: > > > > A: Until the latest glibc release (2.34), statx is only used for 32-bit > > > > platforms, or 64-bit platforms with 32-bit timestamp. I.e., Most 64- > > > > bit platforms still use newstat now. > > > > > > > > Q: Why keep _ARCH_WANT_SYS_CLONE definition while there is clone3: > > > > A: The latest glibc release (2.34) has some basic support for clone3 but > > > > it isn't complete. E.g., pthread_create() and spawni() have converted > > > > to use clone3 but fork() will still use clone. Moreover, some seccomp > > > > related applications can still not work perfectly with clone3. E.g., > > > > Chromium sandbox cannot work at all and there is no solution for it, > > > > which is more terrible than the fork() story [1]. > > > > > > > > [1] https://chromium-review.googlesource.com/c/chromium/src/+/2936184 > > > > > > I still think these have to be removed. There is no mainline glibc or musl > > > port yet, and neither of them should actually be required. Please remove > > > them here, and modify your libc patches accordingly when you send those > > > upstream. > > > > If this is just a problem that can be resolved by upgrading > > glibc/musl, I will remove them. But the Chromium problem (or sandbox > > problem in general) seems to have no solution now. > > I added Christian Brauner to Cc now, maybe he has come across the > sandbox problem before and has an idea for a solution. (I just got back from LSFMM so I'll reply in more detail next week. I'm still pretty jet-lagged.)