lkml.org 
[lkml]   [2014]   [Mar]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [x86, vdso] BUG: unable to handle kernel paging request at d34bd000
From
Date

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




\
 
 \ /
  Last update: 2014-03-07 23:21    [W:0.080 / U:0.076 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site