On Fri, 16 Jun 2017, Michal Hocko wrote: > I am sorry but I have really hard to make the oom reaper a reliable way > to stop all the potential oom lockups go away. I do not want to > reintroduce another potential lockup now.
Please show where this "potential lockup" ever existed in a bug report or a testcase? I have never seen __mmput() block when trying to free the memory it maps. > I also do not see why any > solution should be rushed into. I have proposed a way to go and unless > it is clear that this is not a way forward then I simply do not agree > with any partial workarounds or shortcuts. This is not a shortcut, it is a bug fix. 4.12 kills 1-4 processes unnecessarily as a result of setting MMF_OOM_SKIP incorrectly before the mm's memory can be freed. If you have not seen this issue before, which is why you asked if I ever observed it in practice, then you have not stress tested oom reaping. It is very observable and reproducible. I do not agree that adding additional and obscure locking into __mmput() is the solution to what is plainly and obviously fixed with this simple patch. 4.12 needs to stop killing 2-5 processes on every oom condition instead of 1.
