On Thu, 24 Mar 2011, Geert Uytterhoeven wrote:
From: Jiri Kosina <jkosina@xxxxxxx> Subject: [PATCH] brk: fix min_brk lower bound computation for COMPAT_BRK Even if CONFIG_COMPAT_BRK is set in the kernel configuration, it can still be overriden by randomize_va_space sysctl. If this is the case, the min_brk computation in sys_brk() implementation is wrong, as it solely takes into account COMPAT_BRK setting, assuming that brk start is not randomized. But that might not be the case if randomize_va_space sysctl has been set to '2' at the time the binary has been loaded from disk. In such case, the check has to be done in a same way as in !CONFIG_COMPAT_BRK case. In addition to that, the check for the COMPAT_BRK case introduced back in a5b4592c ("brk: make sys_brk() honor COMPAT_BRK when computing lower bound") is slightly wrong -- the lower bound shouldn't be mm->end_code, but mm->end_data instead, as that's where the legacy applications expect brk section to start (i.e. immediately after last global variable). Signed-off-by: Jiri Kosina <jkosina@xxxxxxx> --- Âmm/mmap.c |  10 +++++++++- Â1 files changed, 9 insertions(+), 1 deletions(-) diff --git a/mm/mmap.c b/mm/mmap.c index 50a4aa0..ca2f164 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -253,7 +253,15 @@ SYSCALL_DEFINE1(brk, unsigned long, brk)    Âdown_write(&mm->mmap_sem); Â#ifdef CONFIG_COMPAT_BRK -    min_brk = mm->end_code; +    /* +    Â* CONFIG_COMPAT_BRK can still be overridden by setting +    Â* randomize_va_space to 2, which will still make mm->start_brk +    Â* to be arbitrarily shifted +    Â*/ +    if (mm->start_brk > PAGE_ALIGN(mm->end_data)) +        min_brk = mm->start_brk; +    else +        min_brk = mm->end_data; Â#else    Âmin_brk = mm->start_brk; Â#endif -- 1.7.3.1Sorry for chiming in this late, but I've just bisected a problem in 2.6.38 to commit 5520e89485252c759ee60d313e9422447659947b ("brk: fix min_brk lower bound computation for COMPAT_BRK"). When booting my very old test ramdisk on Amiga/m68k, it fails like this: | RAMDISK: gzip image found at block 0 | VFS: Mounted root (ext2 filesystem) readonly on device 1:0. | warning: process `update' used the obsolete bdflush system call | Fix your initscripts? | init: cannot open inittab | Kernel panic - not syncing: Attempted to kill init! Sorry for not noticing earlier, I usually boot full Debians under ARAnyM, instead of booting old ramdisks with libc5-based binaries that once were considered new.
Oh well, one has to love the libc5-based binaries indeed. Is the patch below fixing the issue you are seeing on your Amiga/m68k? Thanks. diff --git a/mm/mmap.c b/mm/mmap.c index 2ec8eb5..0a02531 100644 --- a/mm/mmap.c +++ b/mm/mmap.c @@ -262,7 +262,7 @@ SYSCALL_DEFINE1(brk, unsigned long, brk) if (mm->start_brk > PAGE_ALIGN(mm->end_data)) min_brk = mm->start_brk; else - min_brk = mm->end_data; + min_brk = mm->end_code; #else min_brk = mm->start_brk; #endif -- Jiri Kosina SUSE Labs, Novell Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-m68k" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
