Re: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000

[Stefani Seibold <stefani@seibold.net>]

Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold <stefani@seibold.net> wrote:
> > Hi Fengguang,
> >
> > i have build a kernel with the config, but my kvm is unable to start it.
> > I will try to find a way to test your kernek config.
> >
> > One thing is the crash point:
> >
> > The function sysenter_setup was modified by Andy, maybe he has an idea
> > what fails.
> 
> *sigh*
> 
> My host kernel is currently fscked up and won't run KVM.  Also, I want
> to confirm that I'm reproducing exactly what you're seeing, and I
> think it depends on the toolchain.  Can you (Fenguang) do:
> 
> $ ls -l arch/x86/vdso/vdso32*.so
> -rwxrwxr-x. 1 luto luto 4096 Mar  7 10:19 arch/x86/vdso/vdso32-int80.so
> -rwxrwxr-x. 1 luto luto 4116 Mar  7 10:19 arch/x86/vdso/vdso32-sysenter.so
> 
> (Of course, triggering this depends on which image gets selected.)
> 

Yes, that what i also figured out. There are two culprits:
CONFIG_OPTIMIZE_INLINING and CONFIG_X86_PPRO_FENCE. Each of them
increase the size of the code by about 500 bytes.

When i add to file arch/x86/vdso/vdso32/vclock_gettime.c

#undef CONFIG_OPTIMIZE_INLINING
#undef CONFIG_X86_PPRO_FENCE

this will solve the issue.

> Note that we have a .so file that exceeds 4k, i.e. one page.  Then
> read the relevant code and wonder what everyone was smoking when they
> wrote it.  There are so many buffer overflows, screwed up
> initializations, unnecessary and incorrect copies, etc, that I don't
> even want to speculate on what the first failure will be when the
> image is bigger than a page.
>

Right. So the above one will not really solve it. At least when
__vdso_getcpu() code will also become a part of the 32 bit VDSO.
 
> It's easy enough to fix, but someone should figure out what the impact
> will be on the compat vdso case.
> 
> I wonder how hard it would be to change the compat vdso do be a dummy
> image a la the x86_64 fake vsyscall page so that old code can keep
> working (maybe with a performance hit) and new code can use a sane
> image.
> 

That is exactly what i wrote one week ago:

Move the VDSO code before the VDSO compat fixmap area and create a kind
of helper VDSO for the VDSO compat fixmap page, which only calls the
real VDSO. But this would result in a performance regression for the
VDSO compat mode.

- Stefani