On Wednesday 29 January 2014 17:40:54 Wookey wrote:
+++ Arnd Bergmann [2014-01-29 18:14 +0100]:
On Wednesday 29 January 2014 16:36:49 Wookey wrote:
Running 32-bit binaries is quite seriously broken until this is fixed. I presume this currently isn't on anyone's list to fix? I'm not sure who's list it should go on.
Are you running with 4KB or 64KB page size in the kernel? IIRC you cannot really run 32-bit binaries with 64KB page size because of related issues.
I'm not sure. The kernel config has: CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y # CONFIG_ARM64_64K_PAGES is not set CONFIG_PAGEFLAGS_EXTENDED=y # CONFIG_TRANSPARENT_HUGEPAGE is not set
Is that using 64K pages or not?
This is 4K pages, so I was on the wrong track here.
Is there a dynamic switch I can twiddle or does it need a kernel rebuild?
If you turn on CONFIG_ARM64_64K_PAGES, you probably won't be able to load any 32-bit executables any more, or more will fail.
Also, I guess vm.mmap_min_addr becomes settable only in 64K increments, which would not be helpful for you.
I also found this setting in the kernel:
config DEFAULT_MMAP_MIN_ADDR int "Low address space to protect from user allocation" depends on MMU default 4096 help This is the portion of low virtual memory which should be protected from userspace allocation. Keeping a user from writing to low pages can help reduce the impact of kernel NULL pointer bugs.
For most ia64, ppc64 and x86 users with lots of address space a value of 65536 is reasonable and should cause no problems. On arm and other archs it should not be higher than 32768. Programs which use vm86 functionality or have some need to map this low address space will need CAP_SYS_RAWIO or disable this protection by setting the value to 0.
This value can be changed after boot using the /proc/sys/vm/mmap_min_addr tunable.
Arnd