Benjamin Herrenschmidt wrote:
On Tue, 2006-09-19 at 16:35 -0700, Mike Waychison wrote:
Patch attached.
As Andrew points out, the logic is a bit hacky and using a flag in
current->flags to determine whether we have done the retry or not already.
I too think the right approach to being able to handle these kinds of
retries in a more general fashion is to introduce a struct
pagefault_args along the page faulting path. Within it, we could
introduce a reason for the retry so the higher levels would be able to
better understand what to do.
.../...
I need to re-read your mail and Andrew as at this point, I don't quite
see why we need that args and/or that current->flags bit instead of
always returning all the way to userland and let the faulting
instruction happen again (which means you don't block in the kernel, can
take signals etc... thus do you actually need to prevent multiple
retries ?)
Ben.
I think the disconnect here is that the retries in the mmap_sem case and
the returning short for a signal are two different beasts, but they
would both want to use a NOPAGE_RETRY return code.
In the case of a signal, we definitely want to return back to userspace
and deliver it. However, for dropping the mmap_sem while waiting for
the synchronous IO, it's a lot easier to directly rerun the fault
handler so that we can make another pass without allowing the for the
drop (avoiding livelock).
If we were to return to userspace after having dropped mmap_sem (without
updating pte, because mm/vmas may change) we would lose major vs minor
fault accounting as well.
Mike Waychison
-
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]
