Re: [RFC PATCH] oom: Don't count on mm-less current process.

Tetsuo Handa
2014-12-23T13:52:30Z

Michal Hocko wrote:
> > and finally sets SIGKILL on that victim thread. If such a delay
> > happened, that victim thread is free to abuse TIF_MEMDIE for that period.
> > Thus, I thought sending SIGKILL followed by setting TIF_MEMDIE is better.
>
> I don't know, I can hardly find a scenario where it would make any
> difference in the real life. If the victim needs to allocate a memory to
> finish then it would trigger OOM again and have to wait/loop until this
> OOM killer releases the oom zonelist lock just to find out it already
> has TIF_MEMDIE set and can dive into memory reserves. Which way is more
> correct is a question but I wouldn't change it without having a really
> good reason. This whole code is subtle already, let's not make it even
> more so.

gfp_to_alloc_flags() in mm/page_alloc.c sets ALLOC_NO_WATERMARKS if
the victim task has TIF_MEMDIE flag, doesn't it?

if (likely(!(gfp_mask & __GFP_NOMEMALLOC))) {
if (gfp_mask & __GFP_MEMALLOC)
alloc_flags |= ALLOC_NO_WATERMARKS;
else if (in_serving_softirq() && (current->flags & PF_MEMALLOC))
alloc_flags |= ALLOC_NO_WATERMARKS;
else if (!in_interrupt() &&
((current->flags & PF_MEMALLOC) ||
unlikely(test_thread_flag(TIF_MEMDIE))))
alloc_flags |= ALLOC_NO_WATERMARKS;
}

Then, I think deferring SIGKILL might widen race window for abusing TIF_MEMDIE.