Messages in this thread | | | From | (Eric W. Biederman) | Date | Fri, 04 May 2018 10:49:42 -0500 | Subject | Re: [PATCH] memcg: Replace mm->owner with mm->memcg |
| |
Oleg Nesterov <oleg@redhat.com> writes:
> On 05/04, Eric W. Biederman wrote: >> >> Oleg Nesterov <oleg@redhat.com> writes: >> >> > OK, what about exec() ? mm_init_memcg() initializes bprm->mm->memcg early in >> > bprm_mm_init(). What if the execing task migrates before exec_mmap() ? >> >> We need the the cgroup when the mm is initialized. That way we have the >> cgroup information when initializing the mm. > > Yes, we need to initialize new_mm->memcg but iiuc mostly for the error path, > >> I don't know if a lock preventing changing the cgroup in exec or just >> a little bit of code in exec_mmap to ensure mm->memcg is properly set >> is the better approach. > > I'd vote for the change in exec_mmap(). This way mm_init_memcg() can just > nullify mm->memcg.
There is at least one common path where we need the memory control group properly initialized so memory allocations don't escape the memory control group.
do_execveat_common copy_strings get_arg_page get_user_pages_remote __get_user_pages_locked __get_user_pages faultin_page handle_mm_fault count_memcg_event_mm __handle_mm_fault handle_pte_fault do_anonymous_page mem_cgroup_try_charge
I am surprised I can't easily find more. Apparently in load_elf_binary we call elf_mmap after set_new_exec and install_exec_creds, making a gracefull recovery from elf_mmap failures impossible.
In any case we most definitely need the memory control group properly setup before exec_mmap.
Eric
| |