Michal Hocko wrote:
> On Tue 28-11-17 21:41:28, Tetsuo Handa wrote:
> > Due to commit 696453e66630ad45 ("mm, oom: task_will_free_mem should skip
> > oom_reaped tasks") and patch "mm,oom: Use ALLOC_OOM for OOM victim's last
> > second allocation.", thread groups sharing the OOM victim's mm without
> > setting ->signal->oom_mm before task_will_free_mem(current) is called
> > might fail to try ALLOC_OOM allocation attempt.
>
> Look, this is getting insane. The code complexity grows without any
> real users asking for this.
This is the result of applying "mm,oom: Use ALLOC_OOM for OOM victim's
last second allocation." instead of "mm, oom: task_will_free_mem(current)
should ignore MMF_OOM_SKIP for once." More you go per-mm oriented rather
than per-signal oriented or per-thread oriented, more atomicity will be
needed.
> While this might look like an interesting
> excercise to you I really hate the direction you are heading. This code
> will always be just a heuristic and the more complicated it will be the
> bigger chances of other side effects there will be as well.
>
> So NACK to this unless I you can show a _real_ usecase that would
> _suffer_ by this corner case.
But we send SIGKILL to all thread groups sharing the OOM victim's memory.
This means that (though it might be artificial/malicious) there can be
programs which hit this corner case.
This resembles setting TIF_MEMDIE to all threads at mark_oom_victim(),
and (if I understand correctly) cgroup-aware OOM killer discussion is
after all trying to split oom_kill_process() into "printk()" part and
"non-printk()" part.
Also, please don't preserve outdated comments.
--
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>
