On 2018/10/30 21:10, Michal Hocko wrote: > I misunderstood your concern. oom_reaper would back off without > MMF_OOF_SKIP as well. You are right we cannot assume anything about > close callbacks so MMF_OOM_SKIP has to come before that. I will move it > behind the pagetable freeing. > And at that point, your patch can at best wait for only __free_pgtables(), at the cost/risk of complicating exit_mmap() and arch specific code. Also, you are asking for comments to wrong audiences. It is arch maintainers who need to precisely understand the OOM behavior / possibility of OOM lockup, and you must persuade them about restricting/complicating future changes in their arch code due to your wish to allow handover. Without "up-to-dated big fat comments to all relevant functions affected by your change" and "acks from all arch maintainers", I'm sure that people keep making errors/mistakes/overlooks. My patch can wait for completion of (not only exit_mmap() but also) __mmput(), by using simple polling approach. My patch can allow NOMMU kernels to avoid possibility of OOM lockup by setting MMF_OOM_SKIP at __mmput() (and future patch will implement timeout based back off for NOMMU kernels), and allows you to get rid of TIF_MEMDIE (which you recently added to your TODO list) by getting rid of conditional handling of oom_reserves_allowed() and ALLOC_OOM. Your "refusing timeout based next OOM victim selection" keeps everyone unable to safely make forward progress. OOM handling is too much complicated, and nobody can become free from errors/mistakes/overlooks. Look at the reality!
