On Mon, May 19, 2014 at 12:27:29PM +0400, Pavel Emelyanov wrote:
> >
> > What happens if you try to checkpoint a program that's in the vdso or,
> > worse, in a signal frame with the vdso on the stack?
>
> Nothing good, unfortunately :( And this is one of the things we're
> investigating.
>
On 05/15/2014 11:42 PM, Andy Lutomirski wrote:
> On May 14, 2014 8:36 PM, "Pavel Emelyanov" wrote:
>>
>> On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
>>> On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov wrote:
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
> On Wed,
On 05/15/2014 11:42 PM, Andy Lutomirski wrote:
On May 14, 2014 8:36 PM, Pavel Emelyanov xe...@parallels.com wrote:
On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy
On Mon, May 19, 2014 at 12:27:29PM +0400, Pavel Emelyanov wrote:
What happens if you try to checkpoint a program that's in the vdso or,
worse, in a signal frame with the vdso on the stack?
Nothing good, unfortunately :( And this is one of the things we're
investigating.
Cyrill can
On Fri, May 16, 2014 at 03:40:48PM -0700, Andy Lutomirski wrote:
> >>
> >> There are other ways how to find where additional pages are laying but it
> >> would be great if there a straightforward interface for that (ie some mark
> >> in /proc/pid/maps output).
> >
> > I'll try to write a patch in
On Fri, May 16, 2014 at 03:40:48PM -0700, Andy Lutomirski wrote:
There are other ways how to find where additional pages are laying but it
would be great if there a straightforward interface for that (ie some mark
in /proc/pid/maps output).
I'll try to write a patch in time for 3.15.
On 05/16/2014 03:40 PM, Andy Lutomirski wrote:
>
> My current draft is here:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/cleanups
>
> On 64-bit userspace, it results in:
>
> 7fffa1dfd000-7fffa1dfe000 r-xp 00:00 0
> [vdso]
>
On Thu, May 15, 2014 at 3:15 PM, Andy Lutomirski wrote:
> On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov wrote:
>> On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
>>> >
>>> > Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
>>> > variables
>>> > be kind
On Thu, May 15, 2014 at 3:15 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
On 05/16/2014 03:40 PM, Andy Lutomirski wrote:
My current draft is here:
https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/log/?h=vdso/cleanups
On 64-bit userspace, it results in:
7fffa1dfd000-7fffa1dfe000 r-xp 00:00 0
[vdso]
On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov wrote:
> On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
>> >
>> > Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
>> > variables
>> > be kind of immutable constants? If yes, we could calculate where the
On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
> >
> > Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
> > variables
> > be kind of immutable constants? If yes, we could calculate where the
> > additional
> > vma lives without requiring any kind of
On Thu, May 15, 2014 at 2:31 PM, Cyrill Gorcunov wrote:
> On Fri, May 16, 2014 at 12:19:14AM +0400, Cyrill Gorcunov wrote:
>>
>> I see what you mean. We're rather targeting on bare x86-64 at the moment
>> but compat mode is needed as well (not yet implemented though). I'll take
>> a precise look
On Fri, May 16, 2014 at 12:19:14AM +0400, Cyrill Gorcunov wrote:
>
> I see what you mean. We're rather targeting on bare x86-64 at the moment
> but compat mode is needed as well (not yet implemented though). I'll take
> a precise look into this area. Thanks!
Indeed, because we were not running
On Thu, May 15, 2014 at 12:59:04PM -0700, Andy Lutomirski wrote:
> >>
> >> What version and bitness is this?
> >
> > x86-64, 3.15-rc5
>
> Aha. Give tip/x86/vdso or -next a try or boot a 32-bit 3.15-rc kernel
> and you'll see it.
I see what you mean. We're rather targeting on bare x86-64 at the
On Thu, May 15, 2014 at 12:53 PM, Cyrill Gorcunov wrote:
> On Thu, May 15, 2014 at 12:46:34PM -0700, Andy Lutomirski wrote:
>> On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov wrote:
>> > On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
>> >> I can summarize:
>> >>
>> >> On 3.14
On Thu, May 15, 2014 at 12:46:34PM -0700, Andy Lutomirski wrote:
> On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov wrote:
> > On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
> >> I can summarize:
> >>
> >> On 3.14 and before, the vdso is just a bunch of ELF headers and
> >>
On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov wrote:
> On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
>> I can summarize:
>>
>> On 3.14 and before, the vdso is just a bunch of ELF headers and
>> executable data. When executed by 64-bit binaries, it reads from the
>> fixmap
On May 14, 2014 8:36 PM, "Pavel Emelyanov" wrote:
>
> On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
> > On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov wrote:
> >> On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
> >>> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
> >>>
On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
> I can summarize:
>
> On 3.14 and before, the vdso is just a bunch of ELF headers and
> executable data. When executed by 64-bit binaries, it reads from the
> fixmap to do its thing. That is, it reads from kernel addresses that
>
On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
I can summarize:
On 3.14 and before, the vdso is just a bunch of ELF headers and
executable data. When executed by 64-bit binaries, it reads from the
fixmap to do its thing. That is, it reads from kernel addresses that
don't
On May 14, 2014 8:36 PM, Pavel Emelyanov xe...@parallels.com wrote:
On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 2:31 PM,
On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
I can summarize:
On 3.14 and before, the vdso is just a bunch of ELF headers and
executable data. When executed by 64-bit binaries, it reads from the
On Thu, May 15, 2014 at 12:46:34PM -0700, Andy Lutomirski wrote:
On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
I can summarize:
On 3.14 and before, the vdso is just a bunch of ELF headers and
On Thu, May 15, 2014 at 12:53 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Thu, May 15, 2014 at 12:46:34PM -0700, Andy Lutomirski wrote:
On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
I can
On Thu, May 15, 2014 at 12:59:04PM -0700, Andy Lutomirski wrote:
What version and bitness is this?
x86-64, 3.15-rc5
Aha. Give tip/x86/vdso or -next a try or boot a 32-bit 3.15-rc kernel
and you'll see it.
I see what you mean. We're rather targeting on bare x86-64 at the moment
but
On Fri, May 16, 2014 at 12:19:14AM +0400, Cyrill Gorcunov wrote:
I see what you mean. We're rather targeting on bare x86-64 at the moment
but compat mode is needed as well (not yet implemented though). I'll take
a precise look into this area. Thanks!
Indeed, because we were not running 32bit
On Thu, May 15, 2014 at 2:31 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Fri, May 16, 2014 at 12:19:14AM +0400, Cyrill Gorcunov wrote:
I see what you mean. We're rather targeting on bare x86-64 at the moment
but compat mode is needed as well (not yet implemented though). I'll take
a
On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
variables
be kind of immutable constants? If yes, we could calculate where the
additional
vma lives without requiring any kind of [vdso] mark in
On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
variables
be kind of immutable constants? If yes, we could calculate where
On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
> On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov wrote:
>> On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
>>> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
>>> wrote:
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
wrote:
> On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin wrote:
>
>> > In my linux-next all that code got deleted by Andy's "x86, vdso:
>> > Reimplement vdso.so preparation in build-time C" anyway. What kernel
>> > were you looking at?
>>
>>
On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov wrote:
> On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
>> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
>> wrote:
>> > On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin
>> > wrote:
>> >
>> >> > In my linux-next all that code got
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
> On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
> wrote:
> > On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin
> > wrote:
> >
> >> > In my linux-next all that code got deleted by Andy's "x86, vdso:
> >> > Reimplement vdso.so
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
wrote:
> On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin wrote:
>
>> > In my linux-next all that code got deleted by Andy's "x86, vdso:
>> > Reimplement vdso.so preparation in build-time C" anyway. What kernel
>> > were you looking at?
>>
>>
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin wrote:
> > In my linux-next all that code got deleted by Andy's "x86, vdso:
> > Reimplement vdso.so preparation in build-time C" anyway. What kernel
> > were you looking at?
>
> Deleted? It appears in today's -next. arch/x86/vdso/vma.c:124 .
>
>
On Wed, May 14, 2014 at 2:03 PM, Andrew Morton
wrote:
> On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin wrote:
>
>> On 05/14/2014 04:23 PM, Andrew Morton wrote:
>> > On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin
>> > wrote:
>> >
>> >> Hi all,
>> >>
>> >> While fuzzing with trinity inside a KVM
On 05/14/2014 05:03 PM, Andrew Morton wrote:
> On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin wrote:
>
>> On 05/14/2014 04:23 PM, Andrew Morton wrote:
>>> On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin
>>> wrote:
>>>
Hi all,
While fuzzing with trinity inside a KVM tools guest
On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin wrote:
> On 05/14/2014 04:23 PM, Andrew Morton wrote:
> > On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin
> > wrote:
> >
> >> Hi all,
> >>
> >> While fuzzing with trinity inside a KVM tools guest running the latest
> >> -next
> >> kernel I've
On 05/14/2014 04:23 PM, Andrew Morton wrote:
> On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin wrote:
>
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running the latest -next
>> kernel I've stumbled on the following spew:
>>
>> [ 1634.969408] BUG: unable to handle kernel
On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
>
> [ 1634.969408] BUG: unable to handle kernel NULL pointer dereference at
> (null)
> [
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1634.969408] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 1634.970538] IP: special_mapping_fault (mm/mmap.c:2961)
[ 1634.971420] PGD
On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Wed, 14 May 2014
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1634.969408] BUG: unable to handle kernel NULL pointer dereference at
(null)
[ 1634.970538] IP: special_mapping_fault (mm/mmap.c:2961)
[ 1634.971420] PGD
On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin sasha.le...@oracle.com wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1634.969408] BUG: unable to handle kernel NULL pointer dereference at
On 05/14/2014 04:23 PM, Andrew Morton wrote:
On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin sasha.le...@oracle.com wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 1634.969408] BUG: unable to handle
On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin sasha.le...@oracle.com wrote:
On 05/14/2014 04:23 PM, Andrew Morton wrote:
On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin sasha.le...@oracle.com
wrote:
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest
On 05/14/2014 05:03 PM, Andrew Morton wrote:
On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin sasha.le...@oracle.com wrote:
On 05/14/2014 04:23 PM, Andrew Morton wrote:
On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin sasha.le...@oracle.com
wrote:
Hi all,
While fuzzing with trinity inside a
On Wed, May 14, 2014 at 2:03 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Wed, 14 May 2014 16:41:45 -0400 Sasha Levin sasha.le...@oracle.com wrote:
On 05/14/2014 04:23 PM, Andrew Morton wrote:
On Wed, 14 May 2014 11:55:45 -0400 Sasha Levin sasha.le...@oracle.com
wrote:
Hi all,
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin sasha.le...@oracle.com wrote:
In my linux-next all that code got deleted by Andy's x86, vdso:
Reimplement vdso.so preparation in build-time C anyway. What kernel
were you looking at?
Deleted? It appears in today's -next.
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin sasha.le...@oracle.com wrote:
In my linux-next all that code got deleted by Andy's x86, vdso:
Reimplement vdso.so preparation in build-time C anyway. What kernel
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin sasha.le...@oracle.com
wrote:
In my linux-next all that code got deleted by Andy's x86, vdso:
On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin sasha.le...@oracle.com
On Wed, May 14, 2014 at 2:31 PM, Andrew Morton
a...@linux-foundation.org wrote:
On Wed, 14 May 2014 17:11:00 -0400 Sasha Levin sasha.le...@oracle.com wrote:
In my linux-next all that code got deleted by Andy's x86, vdso:
Reimplement vdso.so preparation in build-time C anyway. What kernel
54 matches
Mail list logo
