lkml.org 
[lkml]   [2014]   [Mar]   [10]   [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 Mon, Mar 10, 2014 at 10:48 AM, H. Peter Anvin <hpa@linux.intel.com> wrote:
> On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
>>>
>>> Yes, we'd have to switch the vdso to using syscall access. Doing that
>>> from inside a system call is... "interesting".
>>
>> It's a little less interesting if it just involves changing a vma.
>> It's still tricky, though -- would each struct mm have its own struct
>> file for the vvar page? Can this be done with some
>> vm_operations_struct magic? There are possible races, too, though --
>> another thread could access the thing concurrently with a syscall.
>>
>
> Hint: where is your RIP? Where is the RIP of other processes?
>

Whoa there, I'm not suggesting anything nearly that crazy :)

I'm suggesting changing out the vvar page *for that process*, which is
not executable. The actual vdso code already supports this -- from
userspace's point of view it's the same thing as 'echo acpi_pm >
/sys/devices/system/clocksource/clocksource0/current_clocksource',
except that if the actual clocksource is HPET, the hpet page will be
switched out (presumably with a zero page) while being read.

Other processes are totally irrelevant, unless they share the same
struct mm. (This is why the vvar page can't be in the fixmap for this
to work.)

--Andy


\
 
 \ /
  Last update: 2014-03-10 22:42    [W:0.091 / U:0.932 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site