Messages in this thread | | | From | (Eric W. Biederman) | Date | Wed, 09 May 2018 22:00:00 -0500 | Subject | Re: [PATCH 2/2] memcg: Close the race between migration and installing bprm->mm as mm |
| |
Oleg Nesterov <oleg@redhat.com> writes:
> On 05/04, Eric W. Biederman wrote: >> >> --- a/fs/exec.c >> +++ b/fs/exec.c >> @@ -1044,6 +1044,8 @@ static int exec_mmap(struct mm_struct *mm) >> return 0; >> } >> mmdrop(active_mm); >> + /* The tsk may have migrated before the new mm was attached */ >> + mm_sync_memcg_from_task(tsk); >> return 0; >> } > > call_usermodehelper(). perhaps it makes sense to change flush_old_exec() > to clear PF_KTHREAD/etc before exec_mmap().
Yes. That does look like something to be fixed. In practice while it is rare for anything to be migrated during exec I expect it to be even rarer for kernel threads. But that is a legitimate issue.
I expect all of these lines after exec_mmap actually belong in exec_mmap. Which would then make rearraning the lines easy to ensure mm_sync_memcg_from_task sees PF_KTHREAD cleared. /* * After clearing bprm->mm (to mark that current is using the * prepared mm now), we have nothing left of the original * process. If anything from here on returns an error, the check * in search_binary_handler() will SEGV current. */ bprm->mm = NULL;
set_fs(USER_DS); current->flags &= ~(PF_RANDOMIZE | PF_FORKNOEXEC | PF_KTHREAD | PF_NOFREEZE | PF_NO_SETAFFINITY); flush_thread(); current->personality &= ~bprm->per_clear;
Eric
| |