Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756917AbcC2K72 (ORCPT ); Tue, 29 Mar 2016 06:59:28 -0400 Received: from mout.kundenserver.de ([212.227.126.135]:49556 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756736AbcC2K7X (ORCPT ); Tue, 29 Mar 2016 06:59:23 -0400 From: Arnd Bergmann To: linux-arm-kernel@lists.infradead.org Cc: "Zhangjian (Bamvor)" , Andreas Schwab , young.liuyang@huawei.com, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, catalin.marinas@arm.com, broonie@kernel.org, "jijun (D)" , heiko.carstens@de.ibm.com, linux-kernel@vger.kernel.org, agraf@suse.de, klimov.linux@gmail.com, Yury Norov , jan.dakinevich@gmail.com, joseph@codesourcery.com, gaoyongliang@huawei.com, schwidefsky@de.ibm.com, Nathan_Lynch@mentor.com, Bamvor Zhang Jian , christoph.muellner@theobroma-systems.com Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Date: Tue, 29 Mar 2016 12:58:25 +0200 Message-ID: <4405408.txAtlZbTDH@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: <56F6825B.7000906@huawei.com> References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <6653982.FK62mVSCZO@wuerfel> <56F6825B.7000906@huawei.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:qwtd55UMPDEQuREvjMeOEyDrVzsCvjyqTLo/GvtUCf2j1lLo6rL +ZARNkDFkNSl0PJSY1KcvqWH4Grk1LDfnd4CvgDiiB1tOSZSVF7j0cgpJZEI2jx/HhJew7j ph49EC+IHDM7REnWQg3vtXZ8weu5etFJ0+GJo6bbdHaQAscDn5wrscBZTs3/KWm7B7vz0XR 9+lsWle9S03hl5/zLfiaQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:7g+KWovRaVQ=:VdwMREJKyPi94ZCj5LdZ8T blDxiYNGvSR53WphT0JWuaROiOUxddACt+ig8LIYJBR464mK92LCC4fCM1eVyN/Kb1C/WIAwX Ur3LGYgQ4YaDlVvJu8y3JPqM5FQUHJcvIWY7IC/mG8/EYk6mgu0BEtUL0o2aPQPlXo/55hiPV JQu7Dqaq7xIabD4KafRfad0xFAeL2zxhcZ0drCbIBMXRF3NljCd88xQYPVYRG0BdOuEeB67Pq pIAyvJSGqw6+I1lUacznLB1WIIXt/Tv6Anjo2/jiW4oW9v1DLZgSV80kRSMkA0pfdMDlp34Qa QKmMeuVqkWdhSJi2FcfPJW2MPbMsGcO36S9Gx2FEBdM1HYDBVoVHMi8uLJ063MqMsP84LF+lv eymzO6AlbfGuTkAm8Jb+xioUyYnfDaWd/lbp4nX+zPSaTy5KkVaxfs94EFRDUNkLnmtxulYhu aZRIcn2RYnVCC6w0ytMCjNkjAtb7/w2o6RjK2Kb7BMxqZxdLKswWmH29ZTbop5IGHP1+Y+HiR zNr0w24PDTsfYkoJP5RRMhIS5DBu9XzXK4k6VZWspebGeHTOHH2Gkm8T89PWKpq7VwjccDwJO iqjTcWtJYq2g+8857sIUXX4UD1cICAYva3nApRKIvr5dnhCIA04RVaVz4LhngytYi5hHlq078 73mOReQOCenPZdNybRLxxBynl/75b8J3WW9uig+bzxZE2EAQgg9D4hHx+qOqp4mRtRW257oU1 QWX7C3GgKNsbcwmG Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3305 Lines: 98 On Saturday 26 March 2016 20:36:43 Zhangjian wrote: > Hi, Arnd > > On 2016/3/21 17:43, Arnd Bergmann wrote: > > On Monday 21 March 2016 10:07:49 Andreas Schwab wrote: > >> This patch may fix a few LTP tests. > >> > > > > Thanks for analyzing. > > > >> diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > >> index 3631903..d1010db 100644 > >> --- a/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > >> +++ b/sysdeps/unix/sysv/linux/aarch64/bits/fcntl.h > >> @@ -25,18 +25,29 @@ > >> #define __O_NOFOLLOW 0100000 > >> #define __O_DIRECT 0200000 > >> > >> -#define __O_LARGEFILE 0 > >> +#ifdef __ILP32__ > >> +# define __O_LARGEFILE 0400000 > >> +#else > >> +# define __O_LARGEFILE 0 > >> +#endif > >> > > > > I guess this means I screwed up when I said I'd merged the kernel patch > > that Yury did to fix it, sorry about that. > > > > We need the patch to make all new architecture in the kernel default to > > O_LARGEFILE, and not do this in user space. I'd suggest now to keep the > > patches as part of the ILP32 series after all, to make sure they are > > merged at the point when they are needed. > > I am a little bit confuse about off_t. In "[PATCH 08/33] 32-bit > ABI: introduce ARCH_32BIT_OFF_T config option", it mentioned that all > the new 32bit architecture should use 64bit off_t. Ah, so it is part of the series. I had not checked that here. > Should we define off_t in aarch64(for both ilp32 and lp64) in > typesize.h as following? > > diff --git a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > index 7073493..13b77c5 100644 > --- a/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > +++ b/sysdeps/unix/sysv/linux/aarch64/bits/typesizes.h > @@ -33,7 +33,7 @@ > #define __INO64_T_TYPE __UQUAD_TYPE > #define __MODE_T_TYPE __U32_TYPE > #define __NLINK_T_TYPE __U32_TYPE > -#define __OFF_T_TYPE __SLONGWORD_TYPE > +#define __OFF_T_TYPE __SQUAD_TYPE > #define __OFF64_T_TYPE __SQUAD_TYPE > #define __PID_T_TYPE __S32_TYPE > #define __RLIM_T_TYPE __ULONGWORD_TYPE > > Then we could remove the __USE_FILE_OFFSET64 in stat.h and fcnt.h in > aarch64. And truncate and ftruncate is same as truncate64 and > ftruncate64. I don't know what the glibc developers prefer, but I think the result needs to be something like that: either __OFF_T_TYPE is defined as you write above as a 64-bit type, or the user-visible off_t typedef unconditionally uses __OFF64_T_TYPE rather than __OFF_T_TYPE. > Otherwise we need to handle the pad like yury do it in > stat.h, and we need to handle the bigendian as well: I see. > @@ -35,12 +35,21 @@ struct stat > { > __dev_t st_dev; /* Device. */ > #ifdef __ILP32__ > + > +#if !defined(__AARCH64EB__) > unsigned int __st_ino_pad; > +#endif > + > # ifndef __USE_FILE_OFFSET64 > __ino_t st_ino; /* File serial number. */ > # else > __ino_t __st_ino; /* 32bit file serial number. */ > # endif > + > +#if defined(__AARCH64EB__) > + unsigned int __st_ino_pad; > +#endif > + > #else This would indeed be silly, we really don't want anyone to access the old __st_ino field or the 32-bit version of the offset here. Arnd