Michal Hocko wrote:
> On Thu 07-04-16 20:55:34, Tetsuo Handa wrote:
> > Michal Hocko wrote:
> > > The first obvious one is when the oom victim clears its mm and gets
> > > stuck later on. oom_reaper would back of on find_lock_task_mm returning
> > > NULL. We can safely try to clear TIF_MEMDIE in this case because such a
> > > task would be ignored by the oom killer anyway. The flag would be
> > > cleared by that time already most of the time anyway.
> >
> > I didn't understand what this wants to tell. The OOM victim will clear
> > TIF_MEMDIE as soon as it sets current->mm = NULL.
>
> No it clears the flag _after_ it returns from mmput. There is no
> guarantee it won't get stuck somewhere on the way there - e.g. exit_aio
> waits for completion and who knows what else might get stuck.
OK. Then, I think an OOM livelock scenario shown below is possible.
(1) First OOM victim (where mm->mm_users == 1) is selected by the first
round of out_of_memory() call.
(2) The OOM reaper calls atomic_inc_not_zero(&mm->mm_users).
(3) The OOM victim calls mmput() from exit_mm() from do_exit().
mmput() returns immediately because atomic_dec_and_test(&mm->mm_users)
returns false because of (2).
(4) The OOM reaper reaps memory and then calls mmput().
mmput() calls exit_aio() etc. and waits for completion because
atomic_dec_and_test(&mm->mm_users) is now true.
(5) Second OOM victim (which is the parent of the first OOM victim)
is selected by the next round of out_of_memory() call.
(6) The OOM reaper is waiting for completion of the first OOM victim's
memory while the second OOM victim is waiting for the OOM reaper to
reap memory.
Where is the guarantee that exit_aio() etc. called from mmput() by the
OOM reaper does not depend on memory allocation (i.e. the OOM reaper is
not blocked forever inside __oom_reap_task())?
--
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>