Messages in this thread | | | From | Andrew Lutomirski <> | Date | Mon, 10 Oct 2011 08:31:13 -0700 | Subject | Re: [3.1 patch] x86: default to vsyscall=native |
| |
On Mon, Oct 10, 2011 at 4:48 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * richard -rw- weinberger <richard.weinberger@gmail.com> wrote: > >> From UML's point of view the current situation is odd. UML will no >> longer run on top of a default 3.1 kernel. > > This needs to be fixed (perhaps worked around in UML if that's > possible and if you agree with that) - or barring a real obvious fix > needs to be reverted to the last-known-working state. We are in -rc9 > so nothing but really, really obvious patches can be applied. > >> Why is this odd? One of the major reasons why people are still >> using UML is because you can run it as non-privileged user on any >> x86 Linux host. An user which has root privileges can setup and use >> KVM which is much nicer than UML... > > No, your complaint is entirely justified. > > Andrew?
I think I know what the root cause is and I have most of a patch to fix it. It doesn't compile (yet), it's a little less trivial than I'd like for something this late in the -rc cycle, and it adds 16 bytes to thread_struct (ugh!).
I think I can make a follow-up patch that removes 32 bytes of per-thread state to restore my karma, though, but that will definitely not be 3.1 material.
The issue is that the existing trap_no, error_code, and cr2 fields are used in ways that appear rather broken and extremely fragile to report detailed exception info to user space when SIGSEGV, SIGBUS, and SIGTRAP happen. Touching them from the failed uaccess paths might have unfortunate side effects like breaking vm86. I suspect that nothing other than UML and vm86 users care because they're only used for the old sigcontext data and not for modern siginfo. The tricky case for vsyscall emulation is if gettimeofday is called with a buffer that crosses a page boundary and the second page causes the fault.
I'll email something out in a day or two (maybe today).
--Andy
| |