arm64: Enable CONFIG_COMPAT also for 64k page size

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.

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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -1

index 9532f8d..3cf4f238 100644
@@ -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

Signature · 1 line

1.7.12.4

Quoted 4 lines · 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.

Quoted 3 lines

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?

Quoted 4 lines · 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.

Quoted 3 lines

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.

Quoted 9 lines · Will Deacon

Quoted 7 lines · 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.

Quoted 3 lines

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.

Quoted 14 lines · Alexander Graf

Quoted 12 lines · Will Deacon

Quoted 7 lines · 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.

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.

Quoted 2 lines

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.

Quoted 14 lines · Alexander Graf

Quoted 12 lines · Will Deacon

Quoted 7 lines · 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.

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.

Quoted 2 lines

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.

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

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?

Am 11.03.2015 um 07:47 schrieb Arnd Bergmann <[email protected]>:

Quoted 7 lines · 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.

Quoted 7 lines

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.

From 29457829093014f39c7d1c926c9b86b6cb5709db Mon Sep 17 00:00:00 2001

arch/arm64/kernel/sys32.c asmlinkage long compat_sys_readahead_wrapper(void); · line 45

Quoted 6 lines · On Wednesday 11 March 2015 14:35:39 Andreas Schwab wrote:

arch/arm64/kernel/sys32.c +5 -0

+#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 ;-)

Quoted 9 lines · Arnd Bergmann

arch/arm64/kernel/sys32.c asmlinkage long compat_sys_readahead_wrapper(void); · line 45

Quoted 6 lines · On Wednesday 11 March 2015 14:35:39 Andreas Schwab wrote:

arch/arm64/kernel/sys32.c +5 -0

+#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/

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)?

Quoted 3 lines · Alexander Graf

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.

Quoted 6 lines · 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.

Quoted 7 lines

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.

Quoted 20 lines · Arnd Bergmann

Quoted 6 lines · 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.

Quoted 7 lines

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.

Quoted 3 lines

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?

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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644

Quoted 19 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644
@@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
 

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 6 lines

arch/arm64/Kconfig +0 -1

 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.

Quoted 20 lines · Olof Johansson

Quoted 19 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644
@@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
 

Quoted 10 lines

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 6 lines

arch/arm64/Kconfig +0 -1

 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 ;).

Quoted 3 lines

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.

Quoted 32 lines · Alexander Graf

Quoted 30 lines · Olof Johansson

Quoted 18 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 7 lines

arch/arm64/Kconfig +0 -1

@@ -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.

Quoted 4 lines

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.

Quoted 38 lines · On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:

Quoted 36 lines · Alexander Graf

Quoted 20 lines · Olof Johansson

Quoted 19 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644
@@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
 

Quoted 10 lines

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 6 lines

arch/arm64/Kconfig +0 -1

 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 ;).

Quoted 3 lines

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?

Quoted 2 lines

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).

Quoted 8 lines · On Friday 05 December 2014 11:05:07 Catalin Marinas wrote:

Quoted 2 lines

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.

Quoted 43 lines · Arnd Bergmann

Quoted 41 lines · On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:

Quoted 32 lines · Alexander Graf

Quoted 20 lines · Olof Johansson

Quoted 19 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644
@@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
 

Quoted 10 lines

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 6 lines

arch/arm64/Kconfig +0 -1

 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.

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 38 lines · On Thursday 04 December 2014 15:48:50 Olof Johansson wrote:

Quoted 36 lines · Alexander Graf

Quoted 20 lines · Olof Johansson

Quoted 19 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644
@@ -409,7 +409,6 @@ source "fs/Kconfig.binfmt"
 

Quoted 10 lines

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 6 lines

arch/arm64/Kconfig +0 -1

 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 ;).

Quoted 3 lines

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?

Quoted 18 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 7 lines

arch/arm64/Kconfig +0 -1

@@ -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.

Quoted 31 lines · Olof Johansson

Quoted 18 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 7 lines

arch/arm64/Kconfig +0 -1

@@ -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.

Quoted 3 lines

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.

Quoted 31 lines · Olof Johansson

Quoted 18 lines · 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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -0

index 9532f8d..3cf4f238 100644

arch/arm64/Kconfig source "fs/Kconfig.binfmt" · line 414

Quoted 7 lines

arch/arm64/Kconfig +0 -1

@@ -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.

Quoted 3 lines

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.

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 <[email protected]>

---
 arch/arm64/Kconfig | 1 -
 1 file changed, 1 deletion(-)

arch/arm64/Kconfig +0 -1

index 9532f8d..3cf4f238 100644
@@ -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

Signature · 1 line

1.7.12.4