Searched hist:"4 cc6028d4040f95cdb590a87db478b42b8be0508" (Results 1 – 2 of 2) sorted by relevance
| /linux/arch/alpha/kernel/ |
| H A D | osf_sys.c | diff 2444e56b0c08e6f3e3877583841a1213e3263d98 Thu Apr 24 14:54:50 CEST 2008 Ivan Kokshaysky <ink@jurassic.park.msu.ru> alpha: unbreak OSF/1 (a.out) binaries
OSF/1 brk(2) was broken by following one-liner in sys_brk()
(commit 4cc6028d4040f95cdb590a87db478b42b8be0508):
- if (brk < mm->end_code)
+ if (brk < mm->start_brk)
goto out;
The problem is that osf_set_program_attributes()
does update mm->end_code, but not mm->start_brk,
which still contains inappropriate value left from
binary loader, so brk() always fails.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
|
| /linux/mm/ |
| H A D | mmap.c | diff a5b4592cf77b973c29e7c9695873a26052b58951 Fri Jun 06 07:46:05 CEST 2008 Jiri Kosina <jkosina@suse.cz> brk: make sys_brk() honor COMPAT_BRK when computing lower bound
Fix a regression introduced by
commit 4cc6028d4040f95cdb590a87db478b42b8be0508
Author: Jiri Kosina <jkosina@suse.cz>
Date: Wed Feb 6 22:39:44 2008 +0100
brk: check the lower bound properly
The check in sys_brk() on minimum value the brk might have must take
CONFIG_COMPAT_BRK setting into account. When this option is turned on
(i.e. we support ancient legacy binaries, e.g. libc5-linked stuff), the
lower bound on brk value is mm->end_code, otherwise the brk start is
allowed to be arbitrarily shifted.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Tested-by: Geert Uytterhoeven <geert@linux-m68k.org>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
diff 4cc6028d4040f95cdb590a87db478b42b8be0508 Wed Feb 06 22:39:44 CET 2008 Jiri Kosina <jkosina@suse.cz> brk: check the lower bound properly
There is a check in sys_brk(), that tries to make sure that we do not
underflow the area that is dedicated to brk heap.
The check is however wrong, as it assumes that brk area starts immediately
after the end of the code (+bss), which is wrong for example in
environments with randomized brk start. The proper way is to check whether
the address is not below the start_brk address.
Signed-off-by: Jiri Kosina <jkosina@suse.cz>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
|