Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S965754AbbLWVtp (ORCPT ); Wed, 23 Dec 2015 16:49:45 -0500 Received: from mout.kundenserver.de ([212.227.126.135]:54576 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932483AbbLWVto (ORCPT ); Wed, 23 Dec 2015 16:49:44 -0500 From: Arnd Bergmann To: Yury Norov Subject: Re: [PATCH v6 12/20] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Date: Wed, 23 Dec 2015 22:48:07 +0100 User-Agent: KMail/1.12.2 (Linux/3.19.0-27-generic; KDE/4.3.2; x86_64; ; ) Cc: linux-arm-kernel@lists.infradead.org, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, catalin.marinas@arm.com, broonie@kernel.org, Nathan_Lynch@mentor.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, Andrew Pinski , jan.dakinevich@gmail.com, Andrew Pinski , ddaney.cavm@gmail.com, schwab@suse.de, bamvor.zhangjian@huawei.com, philipp.tomsich@theobroma-systems.com, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com References: <1450215766-14765-1-git-send-email-ynorov@caviumnetworks.com> <201512212331.58152.arnd@arndb.de> <20151223183145.GA27193@yury-N73SV> In-Reply-To: <20151223183145.GA27193@yury-N73SV> MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201512232248.07732.arnd@arndb.de> X-Provags-ID: V03:K0:SK1RaWpPA2YY78SY6R65p9tzfMJqa8RGHnjBD3PfLQETJ6C8eOB 012wusKVwDvwRBWBUdXuX1HflEaI3mVG1NCnmiMYCkw9YPcwT61poi6SIelWenzfx0UAL2Z B+Cn1mM5Q2vZx5rkh9B2Xr7/EKR98B0uiRehVRtZG30d9vq6weTwee6DbCcdYOCRw+7uUP6 Gi/b/MH9UPZ2C41ajOc2A== X-UI-Out-Filterresults: notjunk:1;V01:K0:Dl3gmgebK4E=:Hd14TUy+tLx2HxjMqxYral yshB7nlbYBHnXfoHZ2nyAn2W6k1cd+iTHl0X1CT8zBGFVDLHTXMZfOr0ZmMSWW1BwPVHm3ypG TVndKsxjegT4p+izCeJcAYbMhy2ZpwSSmKWWcLp8dQ4xkppHjYQk/tzVCmHveXbCCYJNW/paP prfhJbJqtA9sLNwD/gJ6m4YornwJMM3j2XwiA7QIOq2oXhyZOEdQklXgO+B8TmbSXGc8Cg60S i5ptzIQCpydVG+rvudKUzvce3A9WLpnN3mKRftXYkOP7W8JmX78+NX9FJNAPu1LFC+fbobMT4 NgKHJyAv/NrwykhFUry8c5PQbjKPCOY4BIpBdGQ7JSrYkZpaAzTJYJgcKZI1PyuvrD7j1LkLP gnU3NVP1W4hsHIUNUzskKQsecMPkp/UW+iF0nq2QDCWn5Q0chD9YudP32WZoNn9/+kZgDRr5g WPCXUcahxOsckbhBCMmOAJ+SnVXf915+EWuHaQyMUo5DVzAPFsYSVvMMVNAMz+CLsBGSdlI/X SfMkqdLtjawdZoB2BOwMpe4zJvdVRL9j6brtT98BXb3Ebwf3mvkKOCK/ZKguliySAe10kK88s DObOr/rVHK130FWhDQT9TQmmIcg4A2U0o/m4h4OwfrAlOBWY0M7fe++vwF963XRbwLvDrGs2T SdNidZ7Vqk4uJhL7yN6IRS3q7qtFL5QOj1wO8itjYTvs/Eza8cam4MJYuYAql9Z97yohAIEi8 IX7vACs1uvcfOyDJ Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3769 Lines: 84 On Wednesday 23 December 2015, Yury Norov wrote: > On Mon, Dec 21, 2015 at 11:31:57PM +0100, Arnd Bergmann wrote: > > On Tuesday 15 December 2015, Yury Norov wrote: > > > + > > > +#define compat_sys_open_by_handle_at sys_open_by_handle_at > > > +#define compat_sys_openat sys_openat > > > + > > > > One more thing I just remembered: I think we want this behavior for all new > > 32-bit architectures, it was a bug to call compat_sys_openat for the generic > > syscall table, as we don't support 32-bit off_t. > > > > Could you split this out into a separate patch that does these changes: > > > > - change the default asm-generic/unistd.h to use sys_openat/sys_open_by_handle_at > > - change tile to override those two to keep the current (suboptimal) behavior > > - change the force_o_largefile() definition so it defaults to true for all future > > architectures. The easiest way is probably to add a Kconfig symbol for this > > that gets selected by all 32-bit architectures, so we can use > > > > #define force_o_largefile() ((BITS_PER_LONG != 32) || !IS_ENABLED(CONFIG_ARCH_32BIT_OFF_T)) > > > > Hi Arnd, > > First two items are OK. The last one... Do you need it to remove > compat_sys_openat and compat_sys_open_by_handle_at? It's needed so all future architectures get it right. > The patch that introduces CONFIG_ARCH_32BIT_OFF_T will affect all > architectures, and so I need to get ack from each maintainer. Just post it to the linux-arch and linux-kernel mailing lists. You are not actually changing behavior, so my Ack should be sufficient here, as long as we make sure we handle all architectures the same way. > I will also have to ask them to test that change, because I have no > access to all the hardware. (Even with QEMU, I cannot test them all.) > I think the only man who is able to success with it is Linus :)... > > Some arches has more than one compat mode. For example ARM64: aarch32 > requires this config enabled, but ilp32 needs it disabled. Now we can > enable both features, but this will make them mutual exclusive. We can > instead (un)define __ARCH_WANT_32BIT_OFF_T for each ABI of each platform, > but it's even more work. And we'd think twice how to do it because > it's not mechanical work. For example, on aarch64 it will look like: > > #define __ARCH_WANT_32BIT_OFF_T is_a32_compat_task() > > I have no idea how it will look on x86 or ppc. arm64 is not affected at all, because it's a 64-bit-only architecture and force_o_largefile() already returns true here. > In your previous email (Nov 18) you write that tile is the only user > of asm-generic/unistd.h that needs compat behaviour. If so, why not > just to turn it around, as you initially suggested, and fix tile. And > do nothing with force_o_largefile()? The first two of the three changes I listed above are for the compat ABI, and there it is enough to change tile. The third change has nothing to do with compat mode, but is about native 32-bit architectures. However, we should change both in sync, so the next architecture that gets added with both native 32-bit mode and compat 32-bit mode on a 64-bit kernel behaves the same way for all 32-bit user space, independent of what the kernel does. We can have two separate patches to clarify that these don't have to be done atomically, but we need to do both for consistency. > By the way, is there a comprehensive list of linux platforms/abis, or > at least ones that use asm-generic/unistd.h? Just the source code. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/