That's been fixed, right?
We can detect this with is_vm_hugetlb_page() if we pass the vma into
pagefault_out_of_memory() without adding another VM_FAULT flag.
See below.
That looks appropriate at first glance.
The filemap, shmem, and block_prepare_write() cases will call the oom
killer but, depending on the gfp mask, they will retry their allocations
after the oom killer is called so we should never return VM_FAULT_OOM
because they return -ENOMEM. They fail from either small objsize slab
allocations or with orders less than PAGE_ALLOC_COSTLY_ORDER which by
default continues to retry even if direct reclaim fails. If we're
returning with VM_FAULT_OOM from these handlers, it should only be because
of GFP_NOFS | __GFP_NORETRY or current has been oom killed and still can't
find memory (so we don't care if the oom killer is called again since it
won't kill anything else).
So like I said, I don't really see a need where VM_FAULT_NO_RESOURCE would
be helpful in any case other than hugetlb which we can already detect by
passing the vma into the pagefault oom handler.
--
