From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753690AbcCUJpA (ORCPT ); Mon, 21 Mar 2016 05:45:00 -0400 Received: from mout.kundenserver.de ([212.227.126.131]:64733 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751696AbcCUJow (ORCPT ); Mon, 21 Mar 2016 05:44:52 -0400 From: Arnd Bergmann To: Andreas Schwab Cc: Yury Norov , "Zhangjian (Bamvor)" , catalin.marinas@arm.com, linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org, pinskia@gmail.com, Prasun.Kapoor@caviumnetworks.com, broonie@kernel.org, heiko.carstens@de.ibm.com, agraf@suse.de, klimov.linux@gmail.com, jan.dakinevich@gmail.com, schwidefsky@de.ibm.com, Nathan_Lynch@mentor.com, joseph@codesourcery.com, christoph.muellner@theobroma-systems.com, Bamvor Zhang Jian Subject: Re: [RFC5 PATCH v6 00/21] ILP32 for ARM64 Date: Mon, 21 Mar 2016 10:43:48 +0100 Message-ID: <6653982.FK62mVSCZO@wuerfel> User-Agent: KMail/4.11.5 (Linux/3.16.0-10-generic; KDE/4.11.5; x86_64; ; ) In-Reply-To: References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <20160318154918.GA1595@yury-N73SV> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:CViMLwPk/2kiSVVw+HnMDIX8N2wWB5U4ufeX4/0EDZQslIK0GaO nKHvDi05MGTqoJmsvrG4Zaxz5M9RDcgzhgRgGiXR292VqxJr4wf9nvIPrx22CB+0bViimQx 9uq2qu/fWo8Gqnlf0SaTcThgNeJr6Ech5AUaE+BRLQVXkr8x1yqG0qzkWMf8mOdBdD/NGVP 2gJrJ0fMwR935C/iNNbWw== X-UI-Out-Filterresults: notjunk:1;V01:K0:zsgpW+jSStg=:SzKmSFaM0oCOcuah9h4HvP dfWzO5yyRhSwY+AQuyWPR32EBV3Fa8j/YK15lWmCCum4QVCwIFEoAwZZNJFnNI3dCwU/glIYp G+VAciAg85UkjfE0ACh3L0015pdhcARNuxVaUXyqPy68OqDeKxmMey7xvdow5VypSXzNhFf+p Ev1goVNX1t5RBjz3JL7dTQdm5FRK0IIod/j5Ahy75e2rdxzy4dziBlY4oAMCuFK/i5b7gOgPZ ZRXQF/1/UcH44+5sh+v393RSu7sycBjJJlV2yKpyx3le+vfTGRyTLNfsGSA7OjXj7PHJDBDal GeVbDT89QWCI+/cYZJ2CjDsD5dmYMh0uAaoR8jHgdUStmUXgUGOmDDnImtQ/aCDIt+I5CuogH IvLj3vWhFl96MPBKLyN63QRQg0YjaCNSwVlmWwiW9/vSQsqEk5Kdj6HqvK6wevVJVBimHD7kJ Y+kpswXjHkd2dPLzMXqEfwFKp1CY2Hsbvr6jESk1rNdr1rqTYDu2FeRT5DvG3E7TTpzkusYQ0 5RAKqypFSitFHDMF4EhfpBtR+BExkH+7o1KrYPfDsjQ6LrzY3AYnHJ8DjSaDZTqzWC2CxHI+t G7Wg+5dA6RUhfxc1u3AI2inIAvtYQ/680XxravtYsMHXdo4Vz0I2r7FKRguw8aS8jT2ZF+KnQ Kt8/1wCDCXp3cGIr4J6vt0lnys0hwXddUBPEjEa35D6bVBlU4dThr/c0aG8h45nu6d8VvZ54z SndAhZUbIJILc3gY Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. > +#ifndef __ILP32__ > # define F_GETLK64 5 > # define F_SETLK64 6 > # define F_SETLKW64 7 > +#endif > > struct flock > { > short int l_type; /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK. */ > short int l_whence; /* Where `l_start' is relative to (like `lseek'). */ > +#ifndef __USE_FILE_OFFSET64 > __off_t l_start; /* Offset where the lock begins. */ > __off_t l_len; /* Size of the locked area; zero means until EOF. */ > +#else > + __off64_t l_start; /* Offset where the lock begins. */ > + __off64_t l_len; /* Size of the locked area; zero means until EOF. */ > +#endif > __pid_t l_pid; /* Process holding the lock. */ > }; This looks like there is another bug as well, but I think this is in libc, not in the kernel. I'm sure we had discussed this at some point but I forgot what the outcome was. Defining 'struct flock' to have a 32-bit l_start and l_len member cannot be right if the kernel only supports 64-bit offsets. My guess is that the libc should either not define __off_t at all for ILP32, and always use __off64_t in struct flock, or __off_t should be defined as __kernel_loff_t a.k.a. long long so the #ifdef can be avoided. What exactly do you need to define F_GETLK64 for on LP64? Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 21 Mar 2016 10:43:48 +0100 Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64 In-Reply-To: References: <1452792198-10718-1-git-send-email-ynorov@caviumnetworks.com> <20160318154918.GA1595@yury-N73SV> Message-ID: <6653982.FK62mVSCZO@wuerfel> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org 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. > +#ifndef __ILP32__ > # define F_GETLK64 5 > # define F_SETLK64 6 > # define F_SETLKW64 7 > +#endif > > struct flock > { > short int l_type; /* Type of lock: F_RDLCK, F_WRLCK, or F_UNLCK. */ > short int l_whence; /* Where `l_start' is relative to (like `lseek'). */ > +#ifndef __USE_FILE_OFFSET64 > __off_t l_start; /* Offset where the lock begins. */ > __off_t l_len; /* Size of the locked area; zero means until EOF. */ > +#else > + __off64_t l_start; /* Offset where the lock begins. */ > + __off64_t l_len; /* Size of the locked area; zero means until EOF. */ > +#endif > __pid_t l_pid; /* Process holding the lock. */ > }; This looks like there is another bug as well, but I think this is in libc, not in the kernel. I'm sure we had discussed this at some point but I forgot what the outcome was. Defining 'struct flock' to have a 32-bit l_start and l_len member cannot be right if the kernel only supports 64-bit offsets. My guess is that the libc should either not define __off_t at all for ILP32, and always use __off64_t in struct flock, or __off_t should be defined as __kernel_loff_t a.k.a. long long so the #ifdef can be avoided. What exactly do you need to define F_GETLK64 for on LP64? Arnd