From fb085cf1d4294824571815d487daccc0609543f0 Mon Sep 17 00:00:00 2001 From: Alexander Nyberg Date: Wed, 14 Sep 2005 18:54:06 +0200 Subject: [PATCH] Fix fs/exec.c:788 (de_thread()) BUG_ON It turns out that the BUG_ON() in fs/exec.c: de_thread() is unreliable and can trigger due to the test itself being racy. de_thread() does while (atomic_read(&sig->count) > count) { } ..... ..... BUG_ON(!thread_group_empty(current)); but release_task does write_lock_irq(&tasklist_lock) __exit_signal (this is where atomic_dec(&sig->count) is run) __exit_sighand __unhash_process takes write lock on tasklist_lock remove itself out of PIDTYPE_TGID list write_unlock_irq(&tasklist_lock) so there's a clear (although small) window between the atomic_dec(&sig->count) and the actual PIDTYPE_TGID unhashing of the thread. And actually there is no need for all threads to have exited at this point, so we simply kill the BUG_ON. Big thanks to Marc Lehmann who provided the test-case. Fixes Bug 5170 (http://bugme.osdl.org/show_bug.cgi?id=5170) Signed-off-by: Alexander Nyberg Cc: Roland McGrath Cc: Andrew Morton Cc: Ingo Molnar Acked-by: Andi Kleen Signed-off-by: Linus Torvalds --- fs/exec.c | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'fs/exec.c') diff --git a/fs/exec.c b/fs/exec.c index 14dd03907ccb..6fae59a22b43 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -745,8 +745,8 @@ static inline int de_thread(struct task_struct *tsk) } /* - * Now there are really no other threads at all, - * so it's safe to stop telling them to kill themselves. + * There may be one thread left which is just exiting, + * but it's safe to stop telling the group to kill themselves. */ sig->flags = 0; @@ -785,7 +785,6 @@ no_thread_group: kmem_cache_free(sighand_cachep, oldsighand); } - BUG_ON(!thread_group_empty(current)); BUG_ON(!thread_group_leader(current)); return 0; } -- cgit v1.2.3 From 2fd4ef85e0db9ed75c98e13953257a967ea55e03 Mon Sep 17 00:00:00 2001 From: Hugh Dickins Date: Wed, 14 Sep 2005 06:13:02 +0100 Subject: [PATCH] error path in setup_arg_pages() misses vm_unacct_memory() Pavel Emelianov and Kirill Korotaev observe that fs and arch users of security_vm_enough_memory tend to forget to vm_unacct_memory when a failure occurs further down (typically in setup_arg_pages variants). These are all users of insert_vm_struct, and that reservation will only be unaccounted on exit if the vma is marked VM_ACCOUNT: which in some cases it is (hidden inside VM_STACK_FLAGS) and in some cases it isn't. So x86_64 32-bit and ppc64 vDSO ELFs have been leaking memory into Committed_AS each time they're run. But don't add VM_ACCOUNT to them, it's inappropriate to reserve against the very unlikely case that gdb be used to COW a vDSO page - we ought to do something about that in do_wp_page, but there are yet other inconsistencies to be resolved. The safe and economical way to fix this is to let insert_vm_struct do the security_vm_enough_memory check when it finds VM_ACCOUNT is set. And the MIPS irix_brk has been calling security_vm_enough_memory before calling do_brk which repeats it, doubly accounting and so also leaking. Remove that, and all the fs and arch calls to security_vm_enough_memory: give it a less misleading name later on. Signed-off-by: Hugh Dickins Signed-Off-By: Kirill Korotaev Signed-off-by: Linus Torvalds --- fs/exec.c | 5 ----- 1 file changed, 5 deletions(-) (limited to 'fs/exec.c') diff --git a/fs/exec.c b/fs/exec.c index 6fae59a22b43..a04a575ad433 100644 --- a/fs/exec.c +++ b/fs/exec.c @@ -421,11 +421,6 @@ int setup_arg_pages(struct linux_binprm *bprm, if (!mpnt) return -ENOMEM; - if (security_vm_enough_memory(arg_size >> PAGE_SHIFT)) { - kmem_cache_free(vm_area_cachep, mpnt); - return -ENOMEM; - } - memset(mpnt, 0, sizeof(*mpnt)); down_write(&mm->mmap_sem); -- cgit v1.2.3