memcg: fix possible panic when CONFIG_MM_OWNER=y

When mm destruction happens, we should pass mm_update_next_owner() the old mm.
But unfortunately new mm is passed in exec_mmap().

Thus, kernel panic is possible when a multi-threaded process uses exec().

Also, the owner member comment description is wrong. mm->owner does not
necessarily point to the thread group leader.

[akpm@linux-foundation.org: coding-style fixes]
Signed-off-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Cc: "Paul Menage" <menage@google.com>
Cc: "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>

authored by KOSAKI Motohiro and committed by Linus Torvalds 4cd1a8fc c9bfcb31

+12 -3
+1 -1
fs/exec.c
··· 736 736 tsk->active_mm = mm; 737 737 activate_mm(active_mm, mm); 738 738 task_unlock(tsk); 739 - mm_update_next_owner(mm); 739 + mm_update_next_owner(old_mm); 740 740 arch_pick_mmap_layout(mm); 741 741 if (old_mm) { 742 742 up_read(&old_mm->mmap_sem);
+11 -2
include/linux/mm_types.h
··· 226 226 rwlock_t ioctx_list_lock; /* aio lock */ 227 227 struct kioctx *ioctx_list; 228 228 #ifdef CONFIG_MM_OWNER 229 - struct task_struct *owner; /* The thread group leader that */ 230 - /* owns the mm_struct. */ 229 + /* 230 + * "owner" points to a task that is regarded as the canonical 231 + * user/owner of this mm. All of the following must be true in 232 + * order for it to be changed: 233 + * 234 + * current == mm->owner 235 + * current->mm != mm 236 + * new_owner->mm == mm 237 + * new_owner->alloc_lock is held 238 + */ 239 + struct task_struct *owner; 231 240 #endif 232 241 233 242 #ifdef CONFIG_PROC_FS