Re: + x86-mm-handle-mm_fault_error-in-kernel-space.patch added to -mm tree

[Oleg Nesterov <oleg@redhat.com>]

On 03/11, Oleg Nesterov wrote:
>
> On 03/11, Andrew Vagin wrote:
> >
> >
> The point is, if current was _NOT_ killed we should follow the current
> pagefault_out_of_memory() logic or remove pagefault_out_of_memory()
> completely.

Yes, and I still think this is valid. And thus I still think the patch
should be changed (btw, this problem is not x86 specific).

However,

> >> Why do you think the current task should be killed? In this case we
> >> do not need oom-killer at all, we could always kill the caller of
> >> alloc_page/etc.
> >
> > You don't understand. alloc_page calls oom-killer himself, then try
> > allocate memory again. Pls look at __alloc_pages_slowpath().
> > __alloc_pages_slowpat may fail if order > 3 || gfp_mask & __GFP_NOFAIL
> > || test_thread_flag(TIF_MEMDIE)
>
> Andrew, please, I know this.

Hmm. It turns out I do not ;)

I thought I can find the case when handle_mm_fault() returns VM_FAULT_OOM
and the caller is not killed, but I can't. I do not really understand
mem_cgroup_handle_oom/etc, but it seems we always retry indefinitely even
with mem_cgroup's. mm/hugetlb.c looks fine too...

So, I have to apologize, I am starting to think you are right.



Maybe someone could explain why pagefault_out_of_memory() is still
needed?

Oleg.