Messages in this thread | | | From | Andrew Lutomirski <> | Date | Thu, 13 Oct 2011 23:30:00 -0700 | Subject | Re: [RFC] fixing the UML failure root cause |
| |
On Thu, Oct 13, 2011 at 9:46 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Oct 13, 2011 at 8:40 PM, Andrew Lutomirski <luto@mit.edu> wrote: >> >> How does that work? The tricky case is when one of those three words >> spans a page boundary if the access to the first page is valid, but >> the access to the second page is not. When that happens, if we report >> the fault as coming from the first page, then UML is likely to get >> think the fault was spurious and enter an infinite loop. > > Hmm. Gaah, I just find that memcpy loop disgusting. >
Yeah, it's not pretty.
> We already have that ugly "uaccess_error" crap in handle_exception(), > we might as well do something like the attached and just say "hey, now > you can catch the page fault information for a get_user/put_user > fault". > > Isn't that much nicer?
I actually tried this. To really get it right, though, I also need to either hook the access_ok failure paths (either every single one or just the ones that matter for those three syscalls, which could be fragile) or to check access_ok separately in the vsyscall emulation code. This also takes up 16 bytes of stack just to support a corner case of a legacy code path.
Another idea is to have a flag that asks the fault handlers to call force_sig_info for us. That's just one bit of per-thread state. Then the vsyscall emulation code could check access_ok, force a signal if access is not ok, then set the flag and do the syscall. And maybe some processes would want to opt in to that mode anyway -- arguably EFAULT is a serious programmer error and should be dealt with more harshly than other syscall misuses.
Admittedly, UML probably doesn't care about recovering vgettimeofday pointed at kernel space...
--Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |