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

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.

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.

--Andy


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