Michal Hocko wrote: > vforked tasks are not really sitting on any memory. They are sharing > the mm with parent until they exec into a new code. Until then it is > just pinning the address space. OOM killer will kill the vforked task > along with its parent but we still can end up selecting vforked task > when the parent wouldn't be selected. E.g. init doing vfork to launch > a task or vforked being a child of oom unkillable task with an updated > oom_score_adj to be killable. > > Make sure to not select vforked task as an oom victim by checking > vfork_done in oom_badness. While vfork()ed task cannot modify userspace memory, can't such task allocate significant amount of kernel memory inside execve() operation (as demonstrated by CVE-2010-4243 64bit_dos.c )? It is possible that killing vfork()ed task releases a lot of memory, isn't it? -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>