Re: [RFC PATCH] mm, oom: allow oom reaper to race with exit_mmap

[David Rientjes]

On Tue, 27 Jun 2017, Tetsuo Handa wrote:

> I wonder why you prefer timeout based approach. Your patch will after all
> set MMF_OOM_SKIP if operations between down_write() and up_write() took
> more than one second. lock_anon_vma_root() from unlink_anon_vmas() from
> free_pgtables() for example calls down_write()/up_write(). unlink_file_vma()
>  from free_pgtables() for another example calls down_write()/up_write().
> This means that it might happen that exit_mmap() takes more than one second
> with mm->mmap_sem held for write, doesn't this?
> 

I certainly have no objection to increasing the timeout period or 
increasing MAX_OOM_REAP_RETRIES to be substantially higher.  All threads 
holding mm->mmap_sem should be oom killed and be able to access memory 
reserves to make forward progress if they fail to reclaim.  If we are 
truly blocked on mm->mmap_sem, waiting longer than one second to declare 
that seems justifiable to prevent the exact situation you describe.