Oleg Nesterov wrote: > On 07/03, Tetsuo Handa wrote: > > > > If kthread_run() in oom_init() fails due to reasons other than OOM > > (e.g. no free pid is available), userspace processes won't be able to > > start as well. > > Why? > > The kernel will boot with or without your change, but > > > Therefore, trying to continue with error message is > > also pointless. > > Can't understand... > > I think this warning makes sense. And since you removed the oom_reaper_the > check in wake_oom_reaper(), the kernel will leak every task_struct passed > to wake_oom_reaper() ? We are trying to prove that OOM livelock is impossible for CONFIG_MMU=y kernels (as long as OOM killer is invoked) because the OOM reaper always gives feedback to the OOM killer, right? Then, preserving code which continues without OOM reaper no longer makes sense. In the past discussion, I suggested Michal to use BUG_ON() or panic() ( http://lkml.kernel.org/r/20151127123525.GG2493@xxxxxxxxxxxxxx ). At that time, we chose continue with pr_err(). If you think that kthread_run() failure in oom_init() will ever happen, I can change my patch to call BUG_ON() or panic(). I don't like continuing without OOM reaper. Anyway, [PATCH 8/8] in this series removes get_task_struct(). Thus, the kernel won't leak every task_struct after all. > > Oleg. > > -- 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>