Michal Hocko wrote:
> On Mon 01-06-15 21:10:18, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > On Mon 01-06-15 19:51:05, Tetsuo Handa wrote:
> > > [...]
> > > > How can all fatal_signal_pending() "struct task_struct" get access to memory
> > > > reserves when only one of fatal_signal_pending() "struct task_struct" has
> > > > TIF_MEMDIE ?
> > >
> > > Because of
> > > /*
> > > * If current has a pending SIGKILL or is exiting, then automatically
> > > * select it. The goal is to allow it to allocate so that it may
> > > * quickly exit and free its memory.
> > > *
> > > * But don't select if current has already released its mm and cleared
> > > * TIF_MEMDIE flag at exit_mm(), otherwise an OOM livelock may occur.
> > > */
> > > if (current->mm &&
> > > (fatal_signal_pending(current) || task_will_free_mem(current))) {
> > > mark_oom_victim(current);
> > > goto out;
> > > }
> >
> > Then, what guarantees that the thread which is between
> > down_write(¤t->mm->mmap_sem) and up_write(¤t->mm->mmap_sem)
> > (or whatever locks which are blocking the OOM victim) calls out_of_memory() ?
> > That thread might be doing !__GFP_FS allocation request.
>
> Could you point to such a place?
I think sequence shown below is possible.
[Thread1-in-Porcess1 Thread2-in-Porcess1] [Thread3-in-Process2]
mutex_lock(&inode->i_mutex);
kmalloc(GFP_KERNEL)
Invokes the OOM killer
Receives TIF_MEMDIE
Receives SIGKILL
Receives SIGKILL
mutex_lock(&inode->i_mutex); <= Waiting forever
kmalloc(GFP_NOFS); <= Can't return because out_of_memory() is not called.
mutex_unlock(&inode->i_mutex);
kmalloc(GFP_NOFS);
mutex_unlock(&inode->i_mutex);
--
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>