On Sat 08-09-18 13:54:12, Tetsuo Handa wrote: [...] I will not comment on the above because I have already done so and you keep ignoring it so I will not waste my time again. But let me ask about the following though > This patch also fixes three possible bugs > > (1) oom_task_origin() tasks can be selected forever because it did not > check for MMF_OOM_SKIP. Is this a real problem. Could you point to any path that wouldn't bail out and oom_origin task would keep trying for ever? If such a path doesn't exist and you believe it is too fragile and point out the older bugs proving that then I can imagine we should care. > (2) sysctl_oom_kill_allocating_task path can be selected forever > because it did not check for MMF_OOM_SKIP. Why is that a problem? sysctl_oom_kill_allocating_task doesn't have any well defined semantic. It is a gross hack to save long and expensive oom victim selection. If we were too strict we should even not allow anybody else but an allocating task to be killed. So selecting it multiple times doesn't sound harmful to me. > (3) CONFIG_MMU=n kernels might livelock because nobody except > is_global_init() case in __oom_kill_process() sets MMF_OOM_SKIP. And now the obligatory question. Is this a real problem? > which prevent proof of "the forward progress guarantee" > and adds one optimization > > (4) oom_evaluate_task() was calling oom_unkillable_task() twice because > oom_evaluate_task() needs to check for !MMF_OOM_SKIP and > oom_task_origin() tasks before calling oom_badness(). ENOPARSE -- Michal Hocko SUSE Labs
