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

From: richard -rw- weinberger
Date: Wed Oct 05 2011 - 18:22:36 EST

On Thu, Oct 6, 2011 at 12:13 AM, Andrew Lutomirski <luto@xxxxxxx> wrote:
> On Mon, Oct 3, 2011 at 10:33 AM, Adrian Bunk <bunk@xxxxxxxxx> wrote:
>> On Mon, Oct 03, 2011 at 06:04:53AM -0700, Andrew Lutomirski wrote:
>>> On Mon, Oct 3, 2011 at 2:08 AM, Adrian Bunk <bunk@xxxxxxxxx> wrote:
>>> > After upgrading a kernel the existing userspace should just work
>>> > (assuming it did work before ;-) ), but when I upgraded my kernel
>>> > from 3.0.4 to 3.1.0-rc8 a UML instance didn't come up properly.
>>> >
>>> > dmesg said:
>>> >  linux-[3800] vsyscall fault (exploit attempt?) ip:ffffffffff600000 cs:33 sp:7fbfb9c498 ax:ffffffffff600000 si:0 di:606790
>>> >  linux-[3856] vsyscall fault (exploit attempt?) ip:ffffffffff600000 cs:33 sp:7fbfb13168 ax:ffffffffff600000 si:0 di:606790
>>> >
>>> > Looking throught the changelog I ended up at commit 3ae36655
>>> > ("x86-64: Rework vsyscall emulation and add vsyscall= parameter").
>>> >
>>> > Linus suggested in to default to
>>> > vsyscall=native.
>>> >
>>> > That sounds reasonable to me, and fixes the problem for me.
>>> At this point in the -rc cycle, this sounds fine.
>>> That being said, I'd like to fix it for real for 3.2.  This particular
>>> failure is suspicious -- the "vsyscall fault" message means that
>>> sys_gettimeofday returned EFAULT, which means that the old (3.0 and
>>> before) vgettimeofday should *also* have segfaulted.
>> This UML kernel binary from 2009 worked for me for all host
>> kernels from 2.6.30 to 3.0, and with 3.1.0-rc8 and vsyscall=native
>> it also seems to run nicely.
>> Looking deeper into "a UML instance didn't come up properly",
>> the problem is that it comes up in a strange (readonly) state.
>> There are "Using makefile-style concurrent boot in runlevel S."
>> and "Using makefile-style concurrent boot in runlevel 2." in the
>> logs with a Debian userspace, but no output from the init scripts
>> in these broken bootups (normal messages are in non-broken bootups).
>> Perhaps the two the messages I see in dmesg on the host are from the
>> processes running rcS and rc2 failing early?
>> In a working startup with a Debian userspace, I'm getting during rcS
>>  Setting the system clock.
>>  Cannot access the Hardware Clock via any known method.
>>  Use the --debug option to see the details of our search for an access method.
>>  Unable to set System Clock to: Mon Oct 3 17:01:35 UTC 2011 ... (warning).
>>> We do have a bit
>>> of a bug in that the new code doesn't report si_addr properly, but
>>> that sounds unlikely as a culprit.  Did you try with the offending
>>> commit reverted (i.e. fce8dc0)?  I bet that it also fails there.
>> fce8dc0 is "x86-64: Wire up getcpu syscall", is that really the one you
>> want me to revert?
>>> What's the .config for your UML binary?  I'd like to see if I can
>>> reproduce this.
>> It's attached.
> I can't reproduce it.  What distro is running inside the UML instance?

Same here.
Adrian, is the UML kernel crashing before executing init?
We definitely need more information...

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at
Please read the FAQ at