Re: [3.1 patch] x86: default to vsyscall=native

[Andrew Lutomirski <luto@mit.edu>]

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