Add cc's. On 09/17, Kyle Walker wrote: > > Currently, the oom killer will attempt to kill a process that is in > TASK_UNINTERRUPTIBLE state. For tasks in this state for an exceptional > period of time, such as processes writing to a frozen filesystem during > a lengthy backup operation, this can result in a deadlock condition as > related processes memory access will stall within the page fault > handler. > > Within oom_unkillable_task(), check for processes in > TASK_UNINTERRUPTIBLE (TASK_KILLABLE omitted). The oom killer will > move on to another task. > > Signed-off-by: Kyle Walker <kwalker@xxxxxxxxxx> > --- > mm/oom_kill.c | 4 ++++ > 1 file changed, 4 insertions(+) > > diff --git a/mm/oom_kill.c b/mm/oom_kill.c > index 1ecc0bc..66f03f8 100644 > --- a/mm/oom_kill.c > +++ b/mm/oom_kill.c > @@ -131,6 +131,10 @@ static bool oom_unkillable_task(struct task_struct *p, > if (memcg && !task_in_mem_cgroup(p, memcg)) > return true; > > + /* Uninterruptible tasks should not be killed unless in TASK_WAKEKILL */ > + if (p->state == TASK_UNINTERRUPTIBLE) > + return true; > + So we can skip a memory hog which, say, does mutex_lock(). And this can't help if this task is multithreaded, unless all its sub-threads are in "D" state too oom killer will pick another thread with the same ->mm. Plus other problems. But yes, such a deadlock is possible. I would really like to see the comments from maintainers. In particular, I seem to recall that someone suggested to try to kill another !TIF_MEMDIE process after timeout, perhaps this is what we should actually do... Oleg. -- 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>