[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

With binutils 2.25 the default alignment for 32bit arm sections changed to
have everything 64k aligned. Armv7 binaries built with this binutils version
run successfully on an arm64 system.

Since effectively there is now the chance to run armv7 code on arm64 even
with 64k page size, it doesn't make sense to block people from enabling
CONFIG_COMPAT on those configurations.

Signed-off-by: Alexander Graf <agraf@suse.de>
---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 9532f8d..3cf4f238 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
 
 config COMPAT
 	bool "Kernel support for 32-bit EL0"
-	depends on !ARM64_64K_PAGES
 	select COMPAT_BINFMT_ELF
 	select HAVE_UID16
 	select OLD_SIGSUSPEND3
-- 
1.7.12.4

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Laura Abbott]

On 12/4/2014 7:46 AM, Alexander Graf wrote:
> With binutils 2.25 the default alignment for 32bit arm sections changed to
> have everything 64k aligned. Armv7 binaries built with this binutils version
> run successfully on an arm64 system.
>
> Since effectively there is now the chance to run armv7 code on arm64 even
> with 64k page size, it doesn't make sense to block people from enabling
> CONFIG_COMPAT on those configurations.
>

It's good to see this restriction dropped. Can we put a note somewhere
in the actual Kconfig about the binutils requirement so the requirements
are more obvious?

Thanks,
Laura

-- 
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum,
hosted by The Linux Foundation

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Will Deacon]

On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
> With binutils 2.25 the default alignment for 32bit arm sections changed to
> have everything 64k aligned. Armv7 binaries built with this binutils version
> run successfully on an arm64 system.
> 
> Since effectively there is now the chance to run armv7 code on arm64 even
> with 64k page size, it doesn't make sense to block people from enabling
> CONFIG_COMPAT on those configurations.

Is there a distro available that is built with a recent enough binutils for
this? I'd really like to run our regression tests to check that page-size
assumptions don't exist for things like shm.

Will

> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/arm64/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9532f8d..3cf4f238 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
>  
>  config COMPAT
>  	bool "Kernel support for 32-bit EL0"
> -	depends on !ARM64_64K_PAGES
>  	select COMPAT_BINFMT_ELF
>  	select HAVE_UID16
>  	select OLD_SIGSUSPEND3
> -- 
> 1.7.12.4
> 
> 

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 04.12.14 19:20, Will Deacon wrote:
> On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>> have everything 64k aligned. Armv7 binaries built with this binutils version
>> run successfully on an arm64 system.
>>
>> Since effectively there is now the chance to run armv7 code on arm64 even
>> with 64k page size, it doesn't make sense to block people from enabling
>> CONFIG_COMPAT on those configurations.
> 
> Is there a distro available that is built with a recent enough binutils for
> this? I'd really like to run our regression tests to check that page-size
> assumptions don't exist for things like shm.

I don't have a full distribution for you yet, but we'll start to switch
to the 2.25 branch soon.

Michael, what are you plans on when a first armv7 Factory build based on
2.25 would be available?


Alex

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Michael Matz]

Hi,

On Fri, 5 Dec 2014, Alexander Graf wrote:

> I don't have a full distribution for you yet, but we'll start to switch 
> to the 2.25 branch soon.
> 
> Michael, what are you plans on when a first armv7 Factory build based on 
> 2.25 would be available?

2.25 isn't released yet, but I just submitted the pre-release version to 
Factory, so the answer would be "as soon as it's checked in" :)


Ciao,
Michael.

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 04.12.14 19:20, Will Deacon wrote:
> On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>> have everything 64k aligned. Armv7 binaries built with this binutils version
>> run successfully on an arm64 system.
>>
>> Since effectively there is now the chance to run armv7 code on arm64 even
>> with 64k page size, it doesn't make sense to block people from enabling
>> CONFIG_COMPAT on those configurations.
> 
> Is there a distro available that is built with a recent enough binutils for
> this? I'd really like to run our regression tests to check that page-size
> assumptions don't exist for things like shm.

So how much of a distro do you need? I could probably assemble a simple
very minimalistic rootfs with only bash if that helps.


Alex

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Will Deacon]

On Sat, Dec 06, 2014 at 05:23:59PM +0000, Alexander Graf wrote:
> On 04.12.14 19:20, Will Deacon wrote:
> > On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
> >> With binutils 2.25 the default alignment for 32bit arm sections changed to
> >> have everything 64k aligned. Armv7 binaries built with this binutils version
> >> run successfully on an arm64 system.
> >>
> >> Since effectively there is now the chance to run armv7 code on arm64 even
> >> with 64k page size, it doesn't make sense to block people from enabling
> >> CONFIG_COMPAT on those configurations.
> > 
> > Is there a distro available that is built with a recent enough binutils for
> > this? I'd really like to run our regression tests to check that page-size
> > assumptions don't exist for things like shm.
> 
> So how much of a distro do you need? I could probably assemble a simple
> very minimalistic rootfs with only bash if that helps.

I'd like to run LTP, so I'd probably need slightly more than that but I
certainly don't need the whole world.

Will

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 08.12.14 11:10, Will Deacon wrote:
> On Sat, Dec 06, 2014 at 05:23:59PM +0000, Alexander Graf wrote:
>> On 04.12.14 19:20, Will Deacon wrote:
>>> On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
>>>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>>>> have everything 64k aligned. Armv7 binaries built with this binutils version
>>>> run successfully on an arm64 system.
>>>>
>>>> Since effectively there is now the chance to run armv7 code on arm64 even
>>>> with 64k page size, it doesn't make sense to block people from enabling
>>>> CONFIG_COMPAT on those configurations.
>>>
>>> Is there a distro available that is built with a recent enough binutils for
>>> this? I'd really like to run our regression tests to check that page-size
>>> assumptions don't exist for things like shm.
>>
>> So how much of a distro do you need? I could probably assemble a simple
>> very minimalistic rootfs with only bash if that helps.
> 
> I'd like to run LTP, so I'd probably need slightly more than that but I
> certainly don't need the whole world.

Let me check with a few folks what we can easily assemble :).


Alex

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 08.12.14 04:10, Will Deacon wrote:
> On Sat, Dec 06, 2014 at 05:23:59PM +0000, Alexander Graf wrote:
>> On 04.12.14 19:20, Will Deacon wrote:
>>> On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
>>>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>>>> have everything 64k aligned. Armv7 binaries built with this binutils version
>>>> run successfully on an arm64 system.
>>>>
>>>> Since effectively there is now the chance to run armv7 code on arm64 even
>>>> with 64k page size, it doesn't make sense to block people from enabling
>>>> CONFIG_COMPAT on those configurations.
>>>
>>> Is there a distro available that is built with a recent enough binutils for
>>> this? I'd really like to run our regression tests to check that page-size
>>> assumptions don't exist for things like shm.
>>
>> So how much of a distro do you need? I could probably assemble a simple
>> very minimalistic rootfs with only bash if that helps.
> 
> I'd like to run LTP, so I'd probably need slightly more than that but I
> certainly don't need the whole world.

So after recompiling all of the distribution with newer binutils we now
have an openSUSE Factory tree that has 64k aligned 32bit binaries.

Unfortunately however, the 32bit glibc has a bogus mmap() implementation
that hard codes 4k page size.

With the patch below applied to glibc, I can successfully run 32bit user
space on Seattle with 64k PAGE_SIZE though. So I guess we'll need to fix
up glibc next.

Do you know of anyone who's fluent enough in 32bit ARM assembly to
convert the hard coded assumptions in there to instead use a variable
that takes the actual host page size into account?


Alex


Index: glibc-2.21/sysdeps/unix/sysv/linux/arm/mmap.S
===================================================================
--- glibc-2.21.orig/sysdeps/unix/sysv/linux/arm/mmap.S
+++ glibc-2.21/sysdeps/unix/sysv/linux/arm/mmap.S
@@ -36,7 +36,7 @@ ENTRY (__mmap)
 	/* convert offset to pages */
 	movs	ip, r5, lsl #20
 	bne	.Linval
-	mov	r5, r5, lsr #12
+	mov	r5, r5, lsr #16

 	/* do the syscall */
 	DO_CALL (mmap2, 0)
Index: glibc-2.21/sysdeps/unix/sysv/linux/arm/mmap64.S
===================================================================
--- glibc-2.21.orig/sysdeps/unix/sysv/linux/arm/mmap64.S
+++ glibc-2.21/sysdeps/unix/sysv/linux/arm/mmap64.S
@@ -43,9 +43,9 @@ ENTRY (__mmap64)
 	cfi_rel_offset (r4, 0)
 	cfi_remember_state
 	movs	r4, ip, lsl $20		@ check that offset is page-aligned
-	mov	ip, ip, lsr $12
+	mov	ip, ip, lsr $16
 	it	eq
-	movseq	r4, r5, lsr $12		@ check for overflow
+	movseq	r4, r5, lsr $16		@ check for overflow
 	bne	.Linval
 	ldr	r4, [sp, $8]		@ load fd
 	orr	r5, ip, r5, lsl $20	@ compose page offset

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Andreas Schwab]

Alexander Graf <agraf@suse.de> writes:

> Unfortunately however, the 32bit glibc has a bogus mmap() implementation
> that hard codes 4k page size.

Which is correct (it's not a page size).

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Arnd Bergmann]

On Wednesday 11 March 2015 06:24:16 Alexander Graf wrote:
> So after recompiling all of the distribution with newer binutils we now
> have an openSUSE Factory tree that has 64k aligned 32bit binaries.
> 
> Unfortunately however, the 32bit glibc has a bogus mmap() implementation
> that hard codes 4k page size.
> 
> With the patch below applied to glibc, I can successfully run 32bit user
> space on Seattle with 64k PAGE_SIZE though. So I guess we'll need to fix
> up glibc next.
> 
> Do you know of anyone who's fluent enough in 32bit ARM assembly to
> convert the hard coded assumptions in there to instead use a variable
> that takes the actual host page size into account?

I believe this is a kernel bug, and the kernel API for 32-bit emulation
should always take the pgoff argument in 4KB units instead of PAGE_SIZE
units, see the implementation of sys_mmap2 in
arch/powerpc/kernel/sys_ppc32.c.

All user space programs that call mmap2 still need to make sure that
their arguments are PAGE_SIZE aligned, but the libc need not care
about this here.

	Arnd

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

> Am 11.03.2015 um 07:47 schrieb Arnd Bergmann <arnd@arndb.de>:
> 
>> On Wednesday 11 March 2015 06:24:16 Alexander Graf wrote:
>> So after recompiling all of the distribution with newer binutils we now
>> have an openSUSE Factory tree that has 64k aligned 32bit binaries.
>> 
>> Unfortunately however, the 32bit glibc has a bogus mmap() implementation
>> that hard codes 4k page size.
>> 
>> With the patch below applied to glibc, I can successfully run 32bit user
>> space on Seattle with 64k PAGE_SIZE though. So I guess we'll need to fix
>> up glibc next.
>> 
>> Do you know of anyone who's fluent enough in 32bit ARM assembly to
>> convert the hard coded assumptions in there to instead use a variable
>> that takes the actual host page size into account?
> 
> I believe this is a kernel bug, and the kernel API for 32-bit emulation
> should always take the pgoff argument in 4KB units instead of PAGE_SIZE
> units, see the implementation of sys_mmap2 in
> arch/powerpc/kernel/sys_ppc32.c.
> 
> All user space programs that call mmap2 still need to make sure that
> their arguments are PAGE_SIZE aligned, but the libc need not care
> about this here.

Awesome, that makes my life a lot easier. Let me cook up a patch that fixes the compat mmap call later today :).


Alex

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Andreas Schwab]

>From 29457829093014f39c7d1c926c9b86b6cb5709db Mon Sep 17 00:00:00 2001
From: Andreas Schwab <schwab@suse.de>
Date: Mon, 9 Mar 2015 17:27:36 +0100
Subject: [PATCH] arm64: fix implementation of mmap2 compat syscall

The arm mmap2 syscall takes the offset in units of 4K, thus with 64K pages
the offset needs to be scaled to units of pages.
---
 arch/arm64/include/asm/unistd32.h |  2 +-
 arch/arm64/kernel/entry32.S       | 18 ++++++++++++++++++
 arch/arm64/kernel/sys32.c         |  6 ++++++
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/unistd32.h b/arch/arm64/include/asm/unistd32.h
index 2722442..cef934a 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -406,7 +406,7 @@ __SYSCALL(__NR_vfork, sys_vfork)
 #define __NR_ugetrlimit 191	/* SuS compliant getrlimit */
 __SYSCALL(__NR_ugetrlimit, compat_sys_getrlimit)		/* SuS compliant getrlimit */
 #define __NR_mmap2 192
-__SYSCALL(__NR_mmap2, sys_mmap_pgoff)
+__SYSCALL(__NR_mmap2, compat_sys_mmap2_wrapper)
 #define __NR_truncate64 193
 __SYSCALL(__NR_truncate64, compat_sys_truncate64_wrapper)
 #define __NR_ftruncate64 194
diff --git a/arch/arm64/kernel/entry32.S b/arch/arm64/kernel/entry32.S
index 9a8f6ae..17f3296 100644
--- a/arch/arm64/kernel/entry32.S
+++ b/arch/arm64/kernel/entry32.S
@@ -19,9 +19,12 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/const.h>
 
 #include <asm/assembler.h>
 #include <asm/asm-offsets.h>
+#include <asm/errno.h>
+#include <asm/page.h>
 
 /*
  * System call wrappers for the AArch32 compatibility layer.
@@ -54,6 +57,21 @@ ENTRY(compat_sys_fstatfs64_wrapper)
 ENDPROC(compat_sys_fstatfs64_wrapper)
 
 /*
+ * Note: off_4k (w5) is always units of 4K.  If we can't do the requested
+ * offset, we return EINVAL.
+ */
+#if PAGE_SHIFT > 12
+ENTRY(compat_sys_mmap2_wrapper)
+	tst	w5, #~PAGE_MASK >> 12
+	b.ne	1f
+	lsr	w5, w5, #PAGE_SHIFT - 12
+	b	sys_mmap_pgoff
+1:	mov	x0, #-EINVAL
+	ret	lr
+ENDPROC(compat_sys_mmap2_wrapper)
+#endif
+
+/*
  * Wrappers for AArch32 syscalls that either take 64-bit parameters
  * in registers or that take 32-bit parameters which require sign
  * extension.
diff --git a/arch/arm64/kernel/sys32.c b/arch/arm64/kernel/sys32.c
index 2d5ab3c..61e416d 100644
--- a/arch/arm64/kernel/sys32.c
+++ b/arch/arm64/kernel/sys32.c
@@ -24,6 +24,7 @@
 
 #include <linux/compiler.h>
 #include <linux/syscalls.h>
+#include <asm/page.h>
 
 asmlinkage long compat_sys_sigreturn_wrapper(void);
 asmlinkage long compat_sys_rt_sigreturn_wrapper(void);
@@ -37,6 +38,11 @@ asmlinkage long compat_sys_readahead_wrapper(void);
 asmlinkage long compat_sys_fadvise64_64_wrapper(void);
 asmlinkage long compat_sys_sync_file_range2_wrapper(void);
 asmlinkage long compat_sys_fallocate_wrapper(void);
+#if PAGE_SIZE > 12
+asmlinkage long compat_sys_mmap2_wrapper(void);
+#else
+#define compat_sys_mmap2_wrapper sys_mmap_pgoff
+#endif
 
 #undef __SYSCALL
 #define __SYSCALL(nr, sym)	[nr] = sym,
-- 
2.3.2


Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Arnd Bergmann]

On Wednesday 11 March 2015 14:35:39 Andreas Schwab wrote:
> +#if PAGE_SIZE > 12
> +asmlinkage long compat_sys_mmap2_wrapper(void);
> +#else
> +#define compat_sys_mmap2_wrapper sys_mmap_pgoff
> +#endif
> 

PAGE_SIZE is always larger than 12 ;-)

	Arnd

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Andreas Schwab]

Arnd Bergmann <arnd@arndb.de> writes:

> On Wednesday 11 March 2015 14:35:39 Andreas Schwab wrote:
>> +#if PAGE_SIZE > 12
>> +asmlinkage long compat_sys_mmap2_wrapper(void);
>> +#else
>> +#define compat_sys_mmap2_wrapper sys_mmap_pgoff
>> +#endif
>> 
>
> PAGE_SIZE is always larger than 12 ;-)

s/PAGE_SIZE/PAGE_SHIFT/

Thanks, Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 11.03.15 08:57, Andreas Schwab wrote:
> Arnd Bergmann <arnd@arndb.de> writes:
> 
>> On Wednesday 11 March 2015 14:35:39 Andreas Schwab wrote:
>>> +#if PAGE_SIZE > 12
>>> +asmlinkage long compat_sys_mmap2_wrapper(void);
>>> +#else
>>> +#define compat_sys_mmap2_wrapper sys_mmap_pgoff
>>> +#endif
>>>
>>
>> PAGE_SIZE is always larger than 12 ;-)
> 
> s/PAGE_SIZE/PAGE_SHIFT/

Yup, that patch does make things work too. With the replacement above

Tested-by: Alexander Graf <agraf@suse.de>

Andreas, would you like to send this upstream as a proper top-level
patch or would you prefer if I do a patch set with the 2 patches (enable
CONFIG_COMPAT on 64k PAGE_SIZE and your patch)?


Alex

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Andreas Schwab]

Alexander Graf <agraf@suse.de> writes:

> Andreas, would you like to send this upstream as a proper top-level
> patch or would you prefer if I do a patch set with the 2 patches (enable
> CONFIG_COMPAT on 64k PAGE_SIZE and your patch)?

They only make sense in combination, so go for the patch set.

Andreas.

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 11.03.15 11:09, Andreas Schwab wrote:
> Alexander Graf <agraf@suse.de> writes:
> 
>> Andreas, would you like to send this upstream as a proper top-level
>> patch or would you prefer if I do a patch set with the 2 patches (enable
>> CONFIG_COMPAT on 64k PAGE_SIZE and your patch)?
> 
> They only make sense in combination, so go for the patch set.

Ok, can you please give me a signed-off-by line for your patch then? :)


Alex

[PATCH] arm64: fix implementation of mmap2 compat syscall

[Andreas Schwab]

The arm mmap2 syscall takes the offset in units of 4K, thus with 64K pages
the offset needs to be scaled to units of pages.

Signed-off-by: Andreas Schwab <schwab@suse.de>
---
 arch/arm64/include/asm/unistd32.h |  2 +-
 arch/arm64/kernel/entry32.S       | 18 ++++++++++++++++++
 arch/arm64/kernel/sys32.c         |  6 ++++++
 3 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/unistd32.h b/arch/arm64/include/asm/unistd32.h
index 2722442..cef934a 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -406,7 +406,7 @@ __SYSCALL(__NR_vfork, sys_vfork)
 #define __NR_ugetrlimit 191	/* SuS compliant getrlimit */
 __SYSCALL(__NR_ugetrlimit, compat_sys_getrlimit)		/* SuS compliant getrlimit */
 #define __NR_mmap2 192
-__SYSCALL(__NR_mmap2, sys_mmap_pgoff)
+__SYSCALL(__NR_mmap2, compat_sys_mmap2_wrapper)
 #define __NR_truncate64 193
 __SYSCALL(__NR_truncate64, compat_sys_truncate64_wrapper)
 #define __NR_ftruncate64 194
diff --git a/arch/arm64/kernel/entry32.S b/arch/arm64/kernel/entry32.S
index 9a8f6ae..17f3296 100644
--- a/arch/arm64/kernel/entry32.S
+++ b/arch/arm64/kernel/entry32.S
@@ -19,9 +19,12 @@
  */
 
 #include <linux/linkage.h>
+#include <linux/const.h>
 
 #include <asm/assembler.h>
 #include <asm/asm-offsets.h>
+#include <asm/errno.h>
+#include <asm/page.h>
 
 /*
  * System call wrappers for the AArch32 compatibility layer.
@@ -54,6 +57,21 @@ ENTRY(compat_sys_fstatfs64_wrapper)
 ENDPROC(compat_sys_fstatfs64_wrapper)
 
 /*
+ * Note: off_4k (w5) is always units of 4K.  If we can't do the requested
+ * offset, we return EINVAL.
+ */
+#if PAGE_SHIFT > 12
+ENTRY(compat_sys_mmap2_wrapper)
+	tst	w5, #~PAGE_MASK >> 12
+	b.ne	1f
+	lsr	w5, w5, #PAGE_SHIFT - 12
+	b	sys_mmap_pgoff
+1:	mov	x0, #-EINVAL
+	ret	lr
+ENDPROC(compat_sys_mmap2_wrapper)
+#endif
+
+/*
  * Wrappers for AArch32 syscalls that either take 64-bit parameters
  * in registers or that take 32-bit parameters which require sign
  * extension.
diff --git a/arch/arm64/kernel/sys32.c b/arch/arm64/kernel/sys32.c
index 2d5ab3c..7800bb1 100644
--- a/arch/arm64/kernel/sys32.c
+++ b/arch/arm64/kernel/sys32.c
@@ -24,6 +24,7 @@
 
 #include <linux/compiler.h>
 #include <linux/syscalls.h>
+#include <asm/page.h>
 
 asmlinkage long compat_sys_sigreturn_wrapper(void);
 asmlinkage long compat_sys_rt_sigreturn_wrapper(void);
@@ -37,6 +38,11 @@ asmlinkage long compat_sys_readahead_wrapper(void);
 asmlinkage long compat_sys_fadvise64_64_wrapper(void);
 asmlinkage long compat_sys_sync_file_range2_wrapper(void);
 asmlinkage long compat_sys_fallocate_wrapper(void);
+#if PAGE_SHIFT > 12
+asmlinkage long compat_sys_mmap2_wrapper(void);
+#else
+#define compat_sys_mmap2_wrapper sys_mmap_pgoff
+#endif
 
 #undef __SYSCALL
 #define __SYSCALL(nr, sym)	[nr] = sym,
-- 
2.3.2

-- 
Andreas Schwab, SUSE Labs, schwab at suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Christopher Covington]

Hi,

On 03/11/2015 08:47 AM, Arnd Bergmann wrote:
> On Wednesday 11 March 2015 06:24:16 Alexander Graf wrote:
>> So after recompiling all of the distribution with newer binutils we now
>> have an openSUSE Factory tree that has 64k aligned 32bit binaries.
>>
>> Unfortunately however, the 32bit glibc has a bogus mmap() implementation
>> that hard codes 4k page size.
>>
>> With the patch below applied to glibc, I can successfully run 32bit user
>> space on Seattle with 64k PAGE_SIZE though. So I guess we'll need to fix
>> up glibc next.
>>
>> Do you know of anyone who's fluent enough in 32bit ARM assembly to
>> convert the hard coded assumptions in there to instead use a variable
>> that takes the actual host page size into account?
> 
> I believe this is a kernel bug, and the kernel API for 32-bit emulation
> should always take the pgoff argument in 4KB units instead of PAGE_SIZE
> units, see the implementation of sys_mmap2 in
> arch/powerpc/kernel/sys_ppc32.c.
> 
> All user space programs that call mmap2 still need to make sure that
> their arguments are PAGE_SIZE aligned, but the libc need not care
> about this here.

What is the correct behavior for /proc/pid/pagemap, /proc/kpagecount, and
/proc/kpageflags for a AArch32 process running on an AArch64 kernel with
non-4K translation granule? Actual page frame number or units-of-4K frame number?

Thanks,
Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Arnd Bergmann]

On Monday 16 March 2015 10:16:37 Christopher Covington wrote:
> 
> On 03/11/2015 08:47 AM, Arnd Bergmann wrote:
> > On Wednesday 11 March 2015 06:24:16 Alexander Graf wrote:
> >> So after recompiling all of the distribution with newer binutils we now
> >> have an openSUSE Factory tree that has 64k aligned 32bit binaries.
> >>
> >> Unfortunately however, the 32bit glibc has a bogus mmap() implementation
> >> that hard codes 4k page size.
> >>
> >> With the patch below applied to glibc, I can successfully run 32bit user
> >> space on Seattle with 64k PAGE_SIZE though. So I guess we'll need to fix
> >> up glibc next.
> >>
> >> Do you know of anyone who's fluent enough in 32bit ARM assembly to
> >> convert the hard coded assumptions in there to instead use a variable
> >> that takes the actual host page size into account?
> > 
> > I believe this is a kernel bug, and the kernel API for 32-bit emulation
> > should always take the pgoff argument in 4KB units instead of PAGE_SIZE
> > units, see the implementation of sys_mmap2 in
> > arch/powerpc/kernel/sys_ppc32.c.
> > 
> > All user space programs that call mmap2 still need to make sure that
> > their arguments are PAGE_SIZE aligned, but the libc need not care
> > about this here.
> 
> What is the correct behavior for /proc/pid/pagemap, /proc/kpagecount, and
> /proc/kpageflags for a AArch32 process running on an AArch64 kernel with
> non-4K translation granule? Actual page frame number or units-of-4K frame number?
> 

Not sure, see what PowerPC does in that case.

	Arnd

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Olof Johansson]

On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
> With binutils 2.25 the default alignment for 32bit arm sections changed to
> have everything 64k aligned. Armv7 binaries built with this binutils version
> run successfully on an arm64 system.
>
> Since effectively there is now the chance to run armv7 code on arm64 even
> with 64k page size, it doesn't make sense to block people from enabling
> CONFIG_COMPAT on those configurations.
>
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/arm64/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9532f8d..3cf4f238 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
>
>  config COMPAT
>         bool "Kernel support for 32-bit EL0"
> -       depends on !ARM64_64K_PAGES
>         select COMPAT_BINFMT_ELF
>         select HAVE_UID16
>         select OLD_SIGSUSPEND3

This is hardly "compat". Sure, it's great to have a new binutils that
has larger alignment, but practically not a single existing binary
will work today if someone tries to do this.

So, it seems very premature to take this off. At the very least
document it like Will requested, and make it depend on !ARM_64K_PAGES
|| EXPERT.


-Olof

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 04.12.14 22:15, Olof Johansson wrote:
> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>> have everything 64k aligned. Armv7 binaries built with this binutils version
>> run successfully on an arm64 system.
>>
>> Since effectively there is now the chance to run armv7 code on arm64 even
>> with 64k page size, it doesn't make sense to block people from enabling
>> CONFIG_COMPAT on those configurations.
>>
>> Signed-off-by: Alexander Graf <agraf@suse.de>
>> ---
>>  arch/arm64/Kconfig | 1 -
>>  1 file changed, 1 deletion(-)
>>
>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>> index 9532f8d..3cf4f238 100644
>> --- a/arch/arm64/Kconfig
>> +++ b/arch/arm64/Kconfig
>> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
>>
>>  config COMPAT
>>         bool "Kernel support for 32-bit EL0"
>> -       depends on !ARM64_64K_PAGES
>>         select COMPAT_BINFMT_ELF
>>         select HAVE_UID16
>>         select OLD_SIGSUSPEND3
> 
> This is hardly "compat". Sure, it's great to have a new binutils that
> has larger alignment, but practically not a single existing binary
> will work today if someone tries to do this.

Yes, but IMHO that's an implementation detail. The same applies for
32bit PPC binaries if you use 4k aligned segments. If your applications
are not aligned for your page size, you can't run them. The only
platform that managed nevertheless FWIW was IA64 ;).

> So, it seems very premature to take this off. At the very least
> document it like Will requested, and make it depend on !ARM_64K_PAGES
> || EXPERT.

Sure, that certainly works for me (though you probably mean Laura).
Completely restricting users from enabling it just because our current
toolchain doesn't generate compatible binaries sounds a bit extreme to me.


Alex

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Olof Johansson]

On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf <agraf@suse.de> wrote:
>
>
> On 04.12.14 22:15, Olof Johansson wrote:
>> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
>>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>>> have everything 64k aligned. Armv7 binaries built with this binutils version
>>> run successfully on an arm64 system.
>>>
>>> Since effectively there is now the chance to run armv7 code on arm64 even
>>> with 64k page size, it doesn't make sense to block people from enabling
>>> CONFIG_COMPAT on those configurations.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>> ---
>>>  arch/arm64/Kconfig | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 9532f8d..3cf4f238 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
>>>
>>>  config COMPAT
>>>         bool "Kernel support for 32-bit EL0"
>>> -       depends on !ARM64_64K_PAGES
>>>         select COMPAT_BINFMT_ELF
>>>         select HAVE_UID16
>>>         select OLD_SIGSUSPEND3
>>
>> This is hardly "compat". Sure, it's great to have a new binutils that
>> has larger alignment, but practically not a single existing binary
>> will work today if someone tries to do this.
>
> Yes, but IMHO that's an implementation detail. The same applies for
> 32bit PPC binaries if you use 4k aligned segments. If your applications
> are not aligned for your page size, you can't run them. The only
> platform that managed nevertheless FWIW was IA64 ;).

Yes, but there the binutils change happened early enough that by the
time the kernel change went in, all major distros had binaries that
were compatible.

>> So, it seems very premature to take this off. At the very least
>> document it like Will requested, and make it depend on !ARM_64K_PAGES
>> || EXPERT.
>
> Sure, that certainly works for me (though you probably mean Laura).

Yeah, sorry Laura. :)

> Completely restricting users from enabling it just because our current
> toolchain doesn't generate compatible binaries sounds a bit extreme to me.

Perhaps.

It's in many ways a timing thing too, if ARM had patched binutils a
couple of years ago it might have been fine to just go with it without
EXPERT now. :)


-Olof

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Arnd Bergmann]

On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:
> On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf <agraf@suse.de> wrote:
> > On 04.12.14 22:15, Olof Johansson wrote:
> >> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
> >>> With binutils 2.25 the default alignment for 32bit arm sections changed to
> >>> have everything 64k aligned. Armv7 binaries built with this binutils version
> >>> run successfully on an arm64 system.
> >>>
> >>> Since effectively there is now the chance to run armv7 code on arm64 even
> >>> with 64k page size, it doesn't make sense to block people from enabling
> >>> CONFIG_COMPAT on those configurations.
> >>>
> >>> Signed-off-by: Alexander Graf <agraf@suse.de>
> >>> ---
> >>>  arch/arm64/Kconfig | 1 -
> >>>  1 file changed, 1 deletion(-)
> >>>
> >>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> >>> index 9532f8d..3cf4f238 100644
> >>> --- a/arch/arm64/Kconfig
> >>> +++ b/arch/arm64/Kconfig
> >>> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
> >>>
> >>>  config COMPAT
> >>>         bool "Kernel support for 32-bit EL0"
> >>> -       depends on !ARM64_64K_PAGES
> >>>         select COMPAT_BINFMT_ELF
> >>>         select HAVE_UID16
> >>>         select OLD_SIGSUSPEND3
> >>
> >> This is hardly "compat". Sure, it's great to have a new binutils that
> >> has larger alignment, but practically not a single existing binary
> >> will work today if someone tries to do this.
> >
> > Yes, but IMHO that's an implementation detail. The same applies for
> > 32bit PPC binaries if you use 4k aligned segments. If your applications
> > are not aligned for your page size, you can't run them. The only
> > platform that managed nevertheless FWIW was IA64 ;).
> 
> Yes, but there the binutils change happened early enough that by the
> time the kernel change went in, all major distros had binaries that
> were compatible.

What is the exact symptom you see when running an unaligned user
space binary on 64k-pages? Do we at least print a helpful error
message somewhere or does it just crash?

Should we add support for 64k-pages in the arm32 kernel as well now?

	Arnd

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Catalin Marinas]

On Fri, Dec 05, 2014 at 10:39:40AM +0000, Arnd Bergmann wrote:
> On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:
> > On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf <agraf@suse.de> wrote:
> > > On 04.12.14 22:15, Olof Johansson wrote:
> > >> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
> > >>> With binutils 2.25 the default alignment for 32bit arm sections changed to
> > >>> have everything 64k aligned. Armv7 binaries built with this binutils version
> > >>> run successfully on an arm64 system.
> > >>>
> > >>> Since effectively there is now the chance to run armv7 code on arm64 even
> > >>> with 64k page size, it doesn't make sense to block people from enabling
> > >>> CONFIG_COMPAT on those configurations.
> > >>>
> > >>> Signed-off-by: Alexander Graf <agraf@suse.de>
> > >>> ---
> > >>>  arch/arm64/Kconfig | 1 -
> > >>>  1 file changed, 1 deletion(-)
> > >>>
> > >>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > >>> index 9532f8d..3cf4f238 100644
> > >>> --- a/arch/arm64/Kconfig
> > >>> +++ b/arch/arm64/Kconfig
> > >>> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
> > >>>
> > >>>  config COMPAT
> > >>>         bool "Kernel support for 32-bit EL0"
> > >>> -       depends on !ARM64_64K_PAGES
> > >>>         select COMPAT_BINFMT_ELF
> > >>>         select HAVE_UID16
> > >>>         select OLD_SIGSUSPEND3
> > >>
> > >> This is hardly "compat". Sure, it's great to have a new binutils that
> > >> has larger alignment, but practically not a single existing binary
> > >> will work today if someone tries to do this.
> > >
> > > Yes, but IMHO that's an implementation detail. The same applies for
> > > 32bit PPC binaries if you use 4k aligned segments. If your applications
> > > are not aligned for your page size, you can't run them. The only
> > > platform that managed nevertheless FWIW was IA64 ;).
> > 
> > Yes, but there the binutils change happened early enough that by the
> > time the kernel change went in, all major distros had binaries that
> > were compatible.
> 
> What is the exact symptom you see when running an unaligned user
> space binary on 64k-pages? Do we at least print a helpful error
> message somewhere or does it just crash?

The application doesn't even start because it cannot map page 0. It
looks like most 32-bit arm binaries are linked to be loaded at 32K.

> Should we add support for 64k-pages in the arm32 kernel as well now?

32-bit LPAE doesn't support 64K pages but IIRC the classic MMU does
(though I have to check whether it was optional). But it's not feasible
to enable this in a 32-bit environment because of the memory wasted with
large pages (on average 32KB per mapped file, possibly even more if you
have lots of small files).

-- 
Catalin

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Arnd Bergmann]

On Friday 05 December 2014 11:05:07 Catalin Marinas wrote:
> 
> > Should we add support for 64k-pages in the arm32 kernel as well now?
> 
> 32-bit LPAE doesn't support 64K pages but IIRC the classic MMU does
> (though I have to check whether it was optional). But it's not feasible
> to enable this in a 32-bit environment because of the memory wasted with
> large pages (on average 32KB per mapped file, possibly even more if you
> have lots of small files).

That sounds like a tradeoff that some users might be willing to make.

I remember that with ps3-linux, a lot of people wanted to enable 64k-pages
because the Cell processor has such a small number of TLB entries (256 or
1024), but Linux only has around 200MB of memory available. I believe
there are arm32 machines with more RAM and fewer TLBs.

	Arnd

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Catalin Marinas]

On Fri, Dec 05, 2014 at 12:24:49PM +0000, Arnd Bergmann wrote:
> On Friday 05 December 2014 11:05:07 Catalin Marinas wrote:
> > 
> > > Should we add support for 64k-pages in the arm32 kernel as well now?
> > 
> > 32-bit LPAE doesn't support 64K pages but IIRC the classic MMU does
> > (though I have to check whether it was optional). But it's not feasible
> > to enable this in a 32-bit environment because of the memory wasted with
> > large pages (on average 32KB per mapped file, possibly even more if you
> > have lots of small files).
> 
> That sounds like a tradeoff that some users might be willing to make.
> 
> I remember that with ps3-linux, a lot of people wanted to enable 64k-pages
> because the Cell processor has such a small number of TLB entries (256 or
> 1024), but Linux only has around 200MB of memory available. I believe
> there are arm32 machines with more RAM and fewer TLBs.

I've heard that the WD MyCloud NAS (Cortex-A9 based) moved to 64K pages
and they rebuilt the filesystem (which annoyed some people that were
previously installing Debian packages directly, they now need
recompilation).

-- 
Catalin

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Christopher Covington]

On 12/05/2014 06:05 AM, Catalin Marinas wrote:
> On Fri, Dec 05, 2014 at 10:39:40AM +0000, Arnd Bergmann wrote:
>> On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:
>>> On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf <agraf@suse.de> wrote:
>>>> On 04.12.14 22:15, Olof Johansson wrote:
>>>>> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
>>>>>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>>>>>> have everything 64k aligned. Armv7 binaries built with this binutils version
>>>>>> run successfully on an arm64 system.
>>>>>>
>>>>>> Since effectively there is now the chance to run armv7 code on arm64 even
>>>>>> with 64k page size, it doesn't make sense to block people from enabling
>>>>>> CONFIG_COMPAT on those configurations.
>>>>>>
>>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>>> ---
>>>>>>  arch/arm64/Kconfig | 1 -
>>>>>>  1 file changed, 1 deletion(-)
>>>>>>
>>>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>>>>> index 9532f8d..3cf4f238 100644
>>>>>> --- a/arch/arm64/Kconfig
>>>>>> +++ b/arch/arm64/Kconfig
>>>>>> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
>>>>>>
>>>>>>  config COMPAT
>>>>>>         bool "Kernel support for 32-bit EL0"
>>>>>> -       depends on !ARM64_64K_PAGES
>>>>>>         select COMPAT_BINFMT_ELF
>>>>>>         select HAVE_UID16
>>>>>>         select OLD_SIGSUSPEND3
>>>>>
>>>>> This is hardly "compat". Sure, it's great to have a new binutils that
>>>>> has larger alignment, but practically not a single existing binary
>>>>> will work today if someone tries to do this.
>>>>
>>>> Yes, but IMHO that's an implementation detail. The same applies for
>>>> 32bit PPC binaries if you use 4k aligned segments. If your applications
>>>> are not aligned for your page size, you can't run them. The only
>>>> platform that managed nevertheless FWIW was IA64 ;).
>>>
>>> Yes, but there the binutils change happened early enough that by the
>>> time the kernel change went in, all major distros had binaries that
>>> were compatible.
>>
>> What is the exact symptom you see when running an unaligned user
>> space binary on 64k-pages? Do we at least print a helpful error
>> message somewhere or does it just crash?
> 
> The application doesn't even start because it cannot map page 0. It
> looks like most 32-bit arm binaries are linked to be loaded at 32K. 

I looked at this briefly and the first problem I narrowed in on was underflow
in the calculation of the off variable in elf_map().

http://lxr.free-electrons.com/source/fs/binfmt_elf.c?v=3.18#L341

Chris

-- 
Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum,
a Linux Foundation Collaborative Project

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Alexander Graf]

On 05.12.14 11:39, Arnd Bergmann wrote:
> On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:
>> On Thu, Dec 4, 2014 at 3:41 PM, Alexander Graf <agraf@suse.de> wrote:
>>> On 04.12.14 22:15, Olof Johansson wrote:
>>>> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
>>>>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>>>>> have everything 64k aligned. Armv7 binaries built with this binutils version
>>>>> run successfully on an arm64 system.
>>>>>
>>>>> Since effectively there is now the chance to run armv7 code on arm64 even
>>>>> with 64k page size, it doesn't make sense to block people from enabling
>>>>> CONFIG_COMPAT on those configurations.
>>>>>
>>>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>>>> ---
>>>>>  arch/arm64/Kconfig | 1 -
>>>>>  1 file changed, 1 deletion(-)
>>>>>
>>>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>>>> index 9532f8d..3cf4f238 100644
>>>>> --- a/arch/arm64/Kconfig
>>>>> +++ b/arch/arm64/Kconfig
>>>>> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
>>>>>
>>>>>  config COMPAT
>>>>>         bool "Kernel support for 32-bit EL0"
>>>>> -       depends on !ARM64_64K_PAGES
>>>>>         select COMPAT_BINFMT_ELF
>>>>>         select HAVE_UID16
>>>>>         select OLD_SIGSUSPEND3
>>>>
>>>> This is hardly "compat". Sure, it's great to have a new binutils that
>>>> has larger alignment, but practically not a single existing binary
>>>> will work today if someone tries to do this.
>>>
>>> Yes, but IMHO that's an implementation detail. The same applies for
>>> 32bit PPC binaries if you use 4k aligned segments. If your applications
>>> are not aligned for your page size, you can't run them. The only
>>> platform that managed nevertheless FWIW was IA64 ;).
>>
>> Yes, but there the binutils change happened early enough that by the
>> time the kernel change went in, all major distros had binaries that
>> were compatible.
> 
> What is the exact symptom you see when running an unaligned user
> space binary on 64k-pages? Do we at least print a helpful error
> message somewhere or does it just crash?

It simply doesn't start:

init-4.2# /hello.binutils-2.23
init-4.2# echo $?
139
init-4.2# /hello.binutils-2.25





Hello world!





init-4.2# echo $?
0
init-4.2#


I'm not sure how to give the user an actually helpful error output here
though. The only real handle we have for executing a binary is to return
an error code.


Alex

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Catalin Marinas]

On Thu, Dec 04, 2014 at 09:15:12PM +0000, Olof Johansson wrote:
> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
> > With binutils 2.25 the default alignment for 32bit arm sections changed to
> > have everything 64k aligned. Armv7 binaries built with this binutils version
> > run successfully on an arm64 system.
> >
> > Since effectively there is now the chance to run armv7 code on arm64 even
> > with 64k page size, it doesn't make sense to block people from enabling
> > CONFIG_COMPAT on those configurations.
> >
> > Signed-off-by: Alexander Graf <agraf@suse.de>
> > ---
> >  arch/arm64/Kconfig | 1 -
> >  1 file changed, 1 deletion(-)
> >
> > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > index 9532f8d..3cf4f238 100644
> > --- a/arch/arm64/Kconfig
> > +++ b/arch/arm64/Kconfig
> > @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
> >
> >  config COMPAT
> >         bool "Kernel support for 32-bit EL0"
> > -       depends on !ARM64_64K_PAGES
> >         select COMPAT_BINFMT_ELF
> >         select HAVE_UID16
> >         select OLD_SIGSUSPEND3
> 
> This is hardly "compat". Sure, it's great to have a new binutils that
> has larger alignment, but practically not a single existing binary
> will work today if someone tries to do this.
> 
> So, it seems very premature to take this off. At the very least
> document it like Will requested, and make it depend on !ARM_64K_PAGES
> || EXPERT.

That would work for me. We need to be clear that most existing 32-bit
binaries will fail.

-- 
Catalin

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Will Deacon]

On Fri, Dec 05, 2014 at 11:14:55AM +0000, Catalin Marinas wrote:
> On Thu, Dec 04, 2014 at 09:15:12PM +0000, Olof Johansson wrote:
> > On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
> > > With binutils 2.25 the default alignment for 32bit arm sections changed to
> > > have everything 64k aligned. Armv7 binaries built with this binutils version
> > > run successfully on an arm64 system.
> > >
> > > Since effectively there is now the chance to run armv7 code on arm64 even
> > > with 64k page size, it doesn't make sense to block people from enabling
> > > CONFIG_COMPAT on those configurations.
> > >
> > > Signed-off-by: Alexander Graf <agraf@suse.de>
> > > ---
> > >  arch/arm64/Kconfig | 1 -
> > >  1 file changed, 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> > > index 9532f8d..3cf4f238 100644
> > > --- a/arch/arm64/Kconfig
> > > +++ b/arch/arm64/Kconfig
> > > @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
> > >
> > >  config COMPAT
> > >         bool "Kernel support for 32-bit EL0"
> > > -       depends on !ARM64_64K_PAGES
> > >         select COMPAT_BINFMT_ELF
> > >         select HAVE_UID16
> > >         select OLD_SIGSUSPEND3
> > 
> > This is hardly "compat". Sure, it's great to have a new binutils that
> > has larger alignment, but practically not a single existing binary
> > will work today if someone tries to do this.
> > 
> > So, it seems very premature to take this off. At the very least
> > document it like Will requested, and make it depend on !ARM_64K_PAGES
> > || EXPERT.
> 
> That would work for me. We need to be clear that most existing 32-bit
> binaries will fail.

I'd still like to run some regression tests to make sure we don't back
ourselves into corners with things like SHMLBA, which would now be less
than a page size.

Will

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Jon Masters]

On 12/05/2014 06:14 AM, Catalin Marinas wrote:
> On Thu, Dec 04, 2014 at 09:15:12PM +0000, Olof Johansson wrote:
>> On Thu, Dec 4, 2014 at 7:46 AM, Alexander Graf <agraf@suse.de> wrote:
>>> With binutils 2.25 the default alignment for 32bit arm sections changed to
>>> have everything 64k aligned. Armv7 binaries built with this binutils version
>>> run successfully on an arm64 system.
>>>
>>> Since effectively there is now the chance to run armv7 code on arm64 even
>>> with 64k page size, it doesn't make sense to block people from enabling
>>> CONFIG_COMPAT on those configurations.
>>>
>>> Signed-off-by: Alexander Graf <agraf@suse.de>
>>> ---
>>>  arch/arm64/Kconfig | 1 -
>>>  1 file changed, 1 deletion(-)
>>>
>>> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
>>> index 9532f8d..3cf4f238 100644
>>> --- a/arch/arm64/Kconfig
>>> +++ b/arch/arm64/Kconfig
>>> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
>>>
>>>  config COMPAT
>>>         bool "Kernel support for 32-bit EL0"
>>> -       depends on !ARM64_64K_PAGES
>>>         select COMPAT_BINFMT_ELF
>>>         select HAVE_UID16
>>>         select OLD_SIGSUSPEND3
>>
>> This is hardly "compat". Sure, it's great to have a new binutils that
>> has larger alignment, but practically not a single existing binary
>> will work today if someone tries to do this.
>>
>> So, it seems very premature to take this off. At the very least
>> document it like Will requested, and make it depend on !ARM_64K_PAGES
>> || EXPERT.
> 
> That would work for me. We need to be clear that most existing 32-bit
> binaries will fail.

Agreed. Btw we intend to ensure that a future Fedora mass rebuild
incorporates this change in alignment on 32-bit to allow 32-bit Fedora
userspace to exist inside a (32-bit personality) chroot on AArch64. This
will allow us to migrate to 64-bit native builders both for 32 and
64-bit in advance of the eventual plan for KVM based build guests.

Jon.

[PATCH] arm64: Enable CONFIG_COMPAT also for 64k page size

[Liviu Dudau]

On Thu, Dec 04, 2014 at 03:46:33PM +0000, Alexander Graf wrote:
> With binutils 2.25 the default alignment for 32bit arm sections changed to
> have everything 64k aligned. Armv7 binaries built with this binutils version
> run successfully on an arm64 system.
> 
> Since effectively there is now the chance to run armv7 code on arm64 even
> with 64k page size, it doesn't make sense to block people from enabling
> CONFIG_COMPAT on those configurations.
> 
> Signed-off-by: Alexander Graf <agraf@suse.de>
> ---
>  arch/arm64/Kconfig | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 9532f8d..3cf4f238 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
>  
>  config COMPAT
>  	bool "Kernel support for 32-bit EL0"
> -	depends on !ARM64_64K_PAGES
>  	select COMPAT_BINFMT_ELF
>  	select HAVE_UID16
>  	select OLD_SIGSUSPEND3
> -- 
> 1.7.12.4
> 

Hi Alexander,

For what is worth, today's linux-next (20141204) does not boot on arm64
if I select CONFIG_ARM64_64K_PAGES. ext4 filesystem fails to mount with:

hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1.2: new high-speed USB device number 3 using ehci-platform
usb-storage 1-1.2:1.0: USB Mass Storage device detected
scsi host0: usb-storage 1-1.2:1.0
atkbd serio0: keyboard reset failed on 1c060000.kmi
Waiting for root device /dev/sda3...
usb 1-1.1: new low-speed USB device number 4 using ehci-platform
input: USB Keyboard as /devices/platform/7ffc0000.ehci/usb1/1-1/1-1.1/1-1.1:1.0/0003:0DC6:3910.0001/input/input2
hid-generic 0003:0DC6:3910.0001: input: USB HID v1.00 Keyboard [USB Keyboard] on usb-7ffc0000.ehci-1.1/input0
input: USB Keyboard as /devices/platform/7ffc0000.ehci/usb1/1-1/1-1.1/1-1.1:1.1/0003:0DC6:3910.0002/input/input3
hid-generic 0003:0DC6:3910.0002: input: USB HID v1.00 Mouse [USB Keyboard] on usb-7ffc0000.ehci-1.1/input1
atkbd serio1: keyboard reset failed on 1c070000.kmi
scsi 0:0:0:0: Direct-Access     Toshiba  StorE HDD        0000 PQ: 0 ANSI: 4
sd 0:0:0:0: [sda] 976773168 512-byte logical blocks: (500 GB/465 GiB)
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 38 00 00 00
sd 0:0:0:0: [sda] No Caching mode page found
sd 0:0:0:0: [sda] Assuming drive cache: write through
 sda: sda1 sda2 sda3
sd 0:0:0:0: [sda] Attached SCSI disk
EXT3-fs (sda3): error: couldn't mount because of unsupported optional features (240)
EXT2-fs (sda3): error: couldn't mount because of unsupported optional features (240)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 128 failed (15930!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 129 failed (54075!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 130 failed (42043!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 131 failed (18746!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 132 failed (19003!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 133 failed (42810!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 134 failed (53306!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 135 failed (15675!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 136 failed (54840!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 137 failed (15161!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 138 failed (19513!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 139 failed (41272!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 140 failed (41529!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 141 failed (20280!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 142 failed (14392!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 143 failed (54585!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 144 failed (44605!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 145 failed (17212!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 146 failed (13372!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 147 failed (55613!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 148 failed (55868!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 149 failed (14141!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 150 failed (16445!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 151 failed (44348!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 152 failed (17983!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 153 failed (43838!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 154 failed (56382!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 155 failed (12607!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 156 failed (12862!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 157 failed (57151!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 158 failed (43071!=0)
EXT4-fs (sda3): ext4_check_descriptors: Checksum for group 159 failed (17726!=0)
EXT4-fs (sda3): ext4_check_descriptors: Inode bitmap for group 160 not in group (block 89328390)!
EXT4-fs (sda3): group descriptors corrupted!
List of all partitions:
b300         1931264 mmcblk0  driver: mmcblk
  b301         1930240 mmcblk0p1 00000000-01
0800       488386584 sda  driver: sd
  0801       125829120 sda1 00000000-01
  0802         5242880 sda2 00000000-02
  0803       357313560 sda3 00000000-03
No filesystem could mount root, tried:  ext3 ext2 ext4 vfat fuseblk
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(8,3)
CPU: 1 PID: 1 Comm: swapper/0 Not tainted 3.18.0-rc7-next-20141204+ #1


Same filesystem (no fsck inbetween) but with a 4K pages kernel boots fine.

Best regards,
Liviu

-- 
====================
| I would like to |
| fix the world,  |
| but they're not |
| giving me the   |
 \ source code!  /
  ---------------
    ?\_(?)_/?