From: arnd@arndb.de (Arnd Bergmann)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC5 PATCH v6 00/21] ILP32 for ARM64
Date: Tue, 29 Mar 2016 12:58:25 +0200 [thread overview]
Message-ID: <4405408.txAtlZbTDH@wuerfel> (raw)
In-Reply-To: <56F6825B.7000906@huawei.com>
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
next prev parent reply other threads:[~2016-03-29 10:58 UTC|newest]
Thread overview: 71+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-14 17:22 [RFC5 PATCH v6 00/21] ILP32 for ARM64 Yury Norov
2016-01-14 17:22 ` [PATCH v6 01/21] arm64: ilp32: add documentation on the ILP32 ABI " Yury Norov
2016-01-14 17:22 ` [PATCH v6 02/21] arm64: ensure the kernel is compiled for LP64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 03/21] arm64: rename COMPAT to AARCH32_EL0 in Kconfig Yury Norov
2016-01-14 17:23 ` [PATCH v6 04/21] arm64: change some CONFIG_COMPAT over to use CONFIG_AARCH32_EL0 instead Yury Norov
2016-01-14 17:23 ` [PATCH v6 05/21] arm64: compat: change config dependences to aarch32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 06/21] arm64:uapi: set __BITS_PER_LONG correctly for ILP32 and LP64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 07/21] thread: move thread bits accessors to separated file Yury Norov
2016-01-14 17:23 ` [PATCH v6 08/21] arm64: introduce is_a32_task and is_a32_thread (for AArch32 compat) Yury Norov
2016-01-14 17:23 ` [PATCH v6 09/21] arm64: ilp32: add is_ilp32_compat_{task, thread} and TIF_32BIT_AARCH64 Yury Norov
2016-01-14 17:23 ` [PATCH v6 10/21] arm64: introduce binfmt_elf32.c Yury Norov
2016-01-14 17:23 ` [PATCH v6 11/21] arm64: ilp32: introduce binfmt_ilp32.c Yury Norov
2016-01-14 17:23 ` [PATCH v6 12/21] arm64: ptrace: handle ptrace_request differently for aarch32 and ilp32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 13/21] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it Yury Norov
2016-01-14 17:23 ` [PATCH v6 14/21] arm64: signal: wrap struct ucontext, fp and lr with struct sigframe Yury Norov
2016-01-14 17:23 ` [PATCH v6 15/21] arm64: signal: share lp64 signal routines to ilp32 Yury Norov
2016-01-14 17:23 ` [PATCH v6 16/21] arm64: signal32: move ilp32 and aarch32 common code to separated file Yury Norov
2016-01-14 17:23 ` [PATCH v6 17/21] arm64: ilp32: introduce ilp32-specific handlers for sigframe Yury Norov
2016-02-29 8:27 ` Andreas Schwab
2016-01-14 17:23 ` [PATCH v6 18/21] arm64:ilp32: add vdso-ilp32 and use for signal return Yury Norov
2016-01-14 17:23 ` [PATCH v6 19/21] arm64:ilp32: add ARM64_ILP32 to Kconfig Yury Norov
2016-01-14 17:23 ` [PATCH v6 20/21] all: s390: make compat wrappers the generic solution Yury Norov
2016-01-14 18:11 ` Yury Norov
2016-01-15 12:46 ` Heiko Carstens
[not found] ` <20160119175223.GA6603@yury-N73SV>
2016-01-20 8:16 ` Heiko Carstens
2016-01-20 12:17 ` Yury Norov
2016-01-14 17:23 ` [PATCH v6 21/21] arm64: ilp32: wrap syscalls to remove top 32-bit vulnerability Yury Norov
2016-01-18 13:18 ` [RFC5 PATCH v6 00/21] ILP32 for ARM64 Zhangjian (Bamvor)
2016-01-18 13:26 ` Andreas Schwab
2016-01-18 13:41 ` Bamvor Zhang Jian
2016-01-29 9:59 ` Zhangjian (Bamvor)
2016-01-29 17:09 ` Yury Norov
2016-01-30 4:15 ` Zhangjian (Bamvor)
2016-02-18 22:35 ` Yury Norov
2016-02-19 8:23 ` Arnd Bergmann
2016-02-19 12:59 ` Yury Norov
2016-02-19 14:06 ` Arnd Bergmann
2016-02-29 15:39 ` Yury Norov
2016-02-29 16:00 ` Andreas Schwab
2016-02-29 16:30 ` Arnd Bergmann
2016-02-25 10:50 ` Andreas Schwab
2016-02-25 20:28 ` Yury Norov
2016-03-18 10:28 ` Zhangjian (Bamvor)
2016-03-18 15:49 ` Yury Norov
2016-03-18 15:55 ` Alexander Graf
2016-03-18 16:46 ` Yury Norov
2016-03-20 8:12 ` Zhangjian (Bamvor)
2016-03-21 11:23 ` Zhangjian (Bamvor)
2016-03-21 18:43 ` Yury Norov
2016-03-22 1:49 ` Yury Norov
2016-03-21 9:07 ` Andreas Schwab
2016-03-21 9:43 ` Arnd Bergmann
2016-03-21 10:52 ` Andreas Schwab
2016-03-21 17:02 ` Arnd Bergmann
2016-03-26 12:36 ` Zhangjian (Bamvor)
2016-03-29 10:58 ` Arnd Bergmann [this message]
2016-03-29 12:01 ` Yury Norov
2016-03-29 12:42 ` Arnd Bergmann
2016-03-29 13:21 ` Zhangjian (Bamvor)
2016-03-29 13:27 ` Arnd Bergmann
2016-03-29 15:54 ` Joseph Myers
2016-03-29 19:30 ` Arnd Bergmann
2016-03-29 20:15 ` Joseph Myers
2016-03-29 20:24 ` Arnd Bergmann
2016-03-29 21:00 ` Joseph Myers
2016-03-29 21:39 ` Arnd Bergmann
2016-03-31 7:35 ` Zhangjian (Bamvor)
2016-03-21 18:40 ` Yury Norov
2016-03-26 13:08 ` Zhangjian (Bamvor)
2016-03-26 13:45 ` Zhangjian (Bamvor)
2016-03-26 22:46 ` Yury Norov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4405408.txAtlZbTDH@wuerfel \
--to=arnd@arndb.de \
--cc=linux-arm-kernel@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox