Possible regression from "fs/exec.c: call arch_pick_mmap_layout() only once"
Subsystems (3)
On my 64bit kernel, commit 283fe963095b38a6ab75dda1436ee66b9e45c7c2 seems to have broken 32bit compatibility. I've run the bisection twice, and verified that reverting this on HEAD fixes the problem. I've uploaded my .config to pastebin at http://pastebin.com/kVcr9H65
Even this simple program:
main(){puts("HELLO");}
compiled with:
gcc -m32 test.c
Will crash with a segfault. Stracing shows that it's failing to allocate memory.
Pat Erley
Am Donnerstag, 2. Januar 2014, 15:41:27 schrieb Pat Erley:
Quoted 7 lines
On my 64bit kernel, commit
283fe963095b38a6ab75dda1436ee66b9e45c7c2seems to have broken 32bit compatibility. I've run the bisection twice, and verified that reverting this on HEAD fixes the problem. I've uploaded my .config to pastebin at http://pastebin.com/kVcr9H65Even this simple program:
Quoted 8 lines
main(){puts("HELLO");}
compiled with:
gcc -m32
test.cWill crash with a segfault. Stracing shows that it's failing to allocate memory.
Good catch!
flush_old_exec() is called before setup_new_exec() and I've removed arch_pick_mmap_layout() from the second call site.
Which turned out to be wrong.
It is wrong because between both callers current->personality is changed. So, we have to remove the first call to arch_pick_mmap_layout() and keep the latter because only then the correct personality is set up.
Can you please test your config with the following patch applied and having 283fe96 reverted?
If it works out for you I'd send an updated patch to Andrew. In the meanwhile I'll double check all call sites...
Thanks,
//richard
---
fs/exec.c +0 -1
@@ -843,7 +843,6 @@ static int exec_mmap(struct mm_struct *mm) tsk->active_mm = mm;activate_mm (active_mm, mm);task_unlock (tsk); -arch_pick_mmap_layout (mm);if (old_mm) {up_read (&old_mm->mmap_sem);BUG_ON (active_mm != old_mm);
Quoted 43 lines · Richard Weinberger
Am Donnerstag, 2. Januar 2014, 15:41:27 schrieb Pat Erley:
Quoted 7 lines
On my 64bit kernel, commit
283fe963095b38a6ab75dda1436ee66b9e45c7c2seems to have broken 32bit compatibility. I've run the bisection twice, and verified that reverting this on HEAD fixes the problem. I've uploaded my .config to pastebin at http://pastebin.com/kVcr9H65Even this simple program:
Quoted 8 lines
main(){puts("HELLO");}
compiled with:
gcc -m32
test.cWill crash with a segfault. Stracing shows that it's failing to allocate memory.
Good catch!
flush_old_exec()is called beforesetup_new_exec()and I've removedarch_pick_mmap_layout()from the second call site.
Which turned out to be wrong.It is wrong because between both callers
current->personalityis changed. So, we have to remove the first call toarch_pick_mmap_layout()and keep the latter because only then the correct personality is set up.Can you please test your config with the following patch applied and having 283fe96 reverted?
If it works out for you I'd send an updated patch to Andrew. In the meanwhile I'll double check all call sites...
Thanks,
//richard---
fs/exec.c +0
-0
fs/exec.c static int exec_mmap(struct mm_struct *mm) · line 848
Quoted 7 lines
fs/exec.c +0
-1@@ -843,7 +843,6 @@ static int exec_mmap(struct mm_struct *mm) tsk->active_mm = mm;activate_mm (active_mm, mm);task_unlock (tsk); -arch_pick_mmap_layout (mm);if (old_mm) {up_read (&old_mm->mmap_sem);BUG_ON (active_mm != old_mm);
Compiling right now. Will test later tonight and let you know.
Pat
Quoted 56 lines · Pat Erley
Quoted 45 lines · Richard Weinberger
Am Donnerstag, 2. Januar 2014, 15:41:27 schrieb Pat Erley:
Quoted 7 lines
On my 64bit kernel, commit
283fe963095b38a6ab75dda1436ee66b9e45c7c2seems to have broken 32bit compatibility. I've run the bisection twice, and verified that reverting this on HEAD fixes the problem. I've uploaded my .config to pastebin at http://pastebin.com/kVcr9H65Even this simple program:
Quoted 8 lines
main(){puts("HELLO");}
compiled with:
gcc -m32
test.cWill crash with a segfault. Stracing shows that it's failing to allocate memory.
Good catch!
flush_old_exec()is called beforesetup_new_exec()and I've removedarch_pick_mmap_layout()from the second call site.
Which turned out to be wrong.It is wrong because between both callers
current->personalityis changed. So, we have to remove the first call toarch_pick_mmap_layout()and keep the
latter because only then the correct personality is set up.Can you please test your config with the following patch applied and having
283fe96 reverted?If it works out for you I'd send an updated patch to Andrew. In the meanwhile I'll double check all call sites...
Thanks,
//richard---
fs/exec.c +0
-0fs/exec.c static int exec_mmap(struct mm_struct *mm) · line 848
Quoted 7 lines
fs/exec.c +0
-1@@ -843,7 +843,6 @@ static int exec_mmap(struct mm_struct *mm) tsk->active_mm = mm;activate_mm (active_mm, mm);task_unlock (tsk); -arch_pick_mmap_layout (mm);if (old_mm) {up_read (&old_mm->mmap_sem);BUG_ON (active_mm != old_mm);Compiling right now. Will test later tonight and let you know.
Quoted 1 line
Pat
I can confirm that this works with 283fe96 reverted.
Pat