Re: [RFC] page fault retry with NOPAGE_RETRY

Andrew Morton
2006-09-20T05:26:56Z

On Wed, 20 Sep 2006 15:04:24 +1000
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Tue, 2006-09-19 at 20:05 -0700, Andrew Morton wrote:
>
> > resides in a pagetable page. Once we've dropped mmap_sem, that
> > pagetable page might not be there any more: munmap() might have freed it.
> > We have to retake mmap_sem, do a find_vma() and a new pagetable walk.
> >
> > There are some optimisations we could make to avoid all of that in the
> > common case, but this is the conceptual behaviour.
>
> It's a non-issue anyway the no_page handler in Mike's patch _does_
> re-take mmap_sem before returning RETRY thus my whole idea still stands
> perfectly fine unless I've missed something, which means we can make it
> without changing no_page arguments. Let me re-describe it:
>
> - somebody->no_page() returns RETRY. It may have dropped the mmap sem,
> but if it did, like in Mike's patch, it will have re-taken it before
> returning.
>
> - upon return (in handle_pte_fault typically) if we get something else
> than that retry, we return
> as usual.
>
> - if we got RETRY we do something like
>
> if (signal_pending(current) || need_resched() || pte_present(*pte))
> return VM_FAULT_MINOR;
> else
> return VM_FAULT_RETRY;
>
> Thus we still have to change arch to test for VM_FAULT_RETRY and loop on
> it (or return to userland if they want but that's less optimal) but we
> don't have to carry around a "MAY_RETRY" thing nor change no_page()
> arguments.
>
> The idea is that we can't livelock since we'll always schedule and we
> can take signals so the process can always be killed.
>
> We'll also avoid the loop and coming back if the PTE has been filled up
> in the meantime (just a cheap optimisation avoiding a new find_vma()
> etc...).
>
> And it's simpler :)
>
> Now, I may have missed something of course, but I'd like to know what.
> So far, I don't see what won't work with the above.
>

It's a choice between two behaviours:

a) get stuck in the kernel until someone kills you and

b) fault the page in and proceed as expected.

Option b) is better, no?