On Wed, 20 Sep 2006 15:04:24 +1000
Benjamin Herrenschmidt <[email protected]> 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?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
