Michal Hocko wrote: > The only case where the oom_reaper is not triggered for the oom victim > is when it shares the memory with a kernel thread (aka use_mm) or with > the global init. After "mm, oom: skip vforked tasks from being selected" > the victim cannot be a vforked task of the global init so we are left > with clone(CLONE_VM) (without CLONE_SIGHAND). use_mm() users are quite > rare as well. CONFIG_MMU=n is the other case where the oom_reaper is not triggered for the oom victim. > > In order to guarantee a forward progress for the OOM killer make > sure that this really rare cases will not get into the way and hide > the mm from the oom killer by setting MMF_OOM_REAPED flag for it. > oom_scan_process_thread will ignore any TIF_MEMDIE task if it has > MMF_OOM_REAPED flag set to catch these oom victims. Nobody will set MMF_OOM_REAPED flag if can_oom_reap == true on CONFIG_MMU=n kernel. If a TIF_MEMDIE thread in CONFIG_MMU=n kernel is blocked before exit_oom_victim() in exit_mm() from do_exit() is called, the system will lock up. This is not handled in the patch nor explained in the changelog. > > After this patch we should guarantee a forward progress for the OOM > killer even when the selected victim is sharing memory with a kernel > thread or global init. -- 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>