On 03/17, Andy Lutomirski wrote:
>
> On Tue, Mar 17, 2015 at 6:43 AM, Oleg Nesterov wrote:
> >
> > But at least the bug exposed by the test-case looks clear:
> >
> > do_linear_fault:
> >
> > vmf->pgoff = (((address & PAGE_MASK) - vma->vm_start) >>
> > PAGE_SHIFT)
> >
On 03/17, Andy Lutomirski wrote:
On Tue, Mar 17, 2015 at 6:43 AM, Oleg Nesterov o...@redhat.com wrote:
But at least the bug exposed by the test-case looks clear:
do_linear_fault:
vmf-pgoff = (((address PAGE_MASK) - vma-vm_start)
PAGE_SHIFT)
On Tue, Mar 17, 2015 at 6:43 AM, Oleg Nesterov wrote:
> On 03/16, Oleg Nesterov wrote:
>>
>> On 03/16, Andy Lutomirski wrote:
>> >
>> > Ick, you're probably right. For what it's worth, the vdso *seems* to
>> > be okay (on 64-bit only, and only if you don't poke at it too hard) if
>> > you mremap
On 03/16, Oleg Nesterov wrote:
>
> On 03/16, Andy Lutomirski wrote:
> >
> > Ick, you're probably right. For what it's worth, the vdso *seems* to
> > be okay (on 64-bit only, and only if you don't poke at it too hard) if
> > you mremap it in one piece. CRIU does that.
>
> I need to run away till
On Tue, Mar 17, 2015 at 6:43 AM, Oleg Nesterov o...@redhat.com wrote:
On 03/16, Oleg Nesterov wrote:
On 03/16, Andy Lutomirski wrote:
Ick, you're probably right. For what it's worth, the vdso *seems* to
be okay (on 64-bit only, and only if you don't poke at it too hard) if
you mremap
On 03/16, Oleg Nesterov wrote:
On 03/16, Andy Lutomirski wrote:
Ick, you're probably right. For what it's worth, the vdso *seems* to
be okay (on 64-bit only, and only if you don't poke at it too hard) if
you mremap it in one piece. CRIU does that.
I need to run away till tomorrow,
On 03/16, Andy Lutomirski wrote:
>
> Ick, you're probably right. For what it's worth, the vdso *seems* to
> be okay (on 64-bit only, and only if you don't poke at it too hard) if
> you mremap it in one piece. CRIU does that.
I need to run away till tomorrow, but looking at this code even if
Thanks for looking over all this, guys. Really appreciated.
On 03/16/2015 07:01 PM, Oleg Nesterov wrote:
> is wrong. To verify, I changed show_map_vma() to expose pgoff even if !file,
> but this test-case can show the problem too:
Might be good to add tests like this to selftests/ once all
this
[cc: linux-mm]
On Mon, Mar 16, 2015 at 12:01 PM, Oleg Nesterov wrote:
> On 03/12, Oleg Nesterov wrote:
>>
>> OTOH. We can probably add ->access() into special_mapping_vmops, this
>> way __access_remote_vm() could work even if gup() fails ?
>
> So I tried to think how
On 03/12, Oleg Nesterov wrote:
>
> OTOH. We can probably add ->access() into special_mapping_vmops, this
> way __access_remote_vm() could work even if gup() fails ?
So I tried to think how special_mapping_vmops->access() can work, it
needs to rely on ->vm_pgoff.
But afaics this logic is just
[cc: linux-mm]
On Mon, Mar 16, 2015 at 12:01 PM, Oleg Nesterov o...@redhat.com wrote:
On 03/12, Oleg Nesterov wrote:
OTOH. We can probably add -access() into special_mapping_vmops, this
way __access_remote_vm() could work even if gup() fails ?
So I tried to think how
On 03/12, Oleg Nesterov wrote:
OTOH. We can probably add -access() into special_mapping_vmops, this
way __access_remote_vm() could work even if gup() fails ?
So I tried to think how special_mapping_vmops-access() can work, it
needs to rely on -vm_pgoff.
But afaics this logic is just broken.
Thanks for looking over all this, guys. Really appreciated.
On 03/16/2015 07:01 PM, Oleg Nesterov wrote:
is wrong. To verify, I changed show_map_vma() to expose pgoff even if !file,
but this test-case can show the problem too:
Might be good to add tests like this to selftests/ once all
this
On 03/16, Andy Lutomirski wrote:
Ick, you're probably right. For what it's worth, the vdso *seems* to
be okay (on 64-bit only, and only if you don't poke at it too hard) if
you mremap it in one piece. CRIU does that.
I need to run away till tomorrow, but looking at this code even if one
On 03/12, Andy Lutomirski wrote:
>
> What's wrong with off-topic? :)
OK ;)
> As vvar demonstrates, it's possible to add new per-process vmas that
> show up in all processes automatically. The trickiest part is making
> it work with CRIU.
Ah... I seem to finaly understand why exactly you added
On 03/13, Sergio Durigan Junior wrote:
>
> On Thursday, March 12 2015, Oleg Nesterov wrote:
>
> > And it seems that we all agree that the kernel should not dump this vma
> > too. Could you confirm that this is fine from gdb pov just in case?
>
> Yes, this is what we expect from the GDB side. This
On 03/12, Andy Lutomirski wrote:
What's wrong with off-topic? :)
OK ;)
As vvar demonstrates, it's possible to add new per-process vmas that
show up in all processes automatically. The trickiest part is making
it work with CRIU.
Ah... I seem to finaly understand why exactly you added this
On 03/13, Sergio Durigan Junior wrote:
On Thursday, March 12 2015, Oleg Nesterov wrote:
And it seems that we all agree that the kernel should not dump this vma
too. Could you confirm that this is fine from gdb pov just in case?
Yes, this is what we expect from the GDB side. This mapping
On Thursday, March 12 2015, Oleg Nesterov wrote:
>> If I understood this discussion correctly (and thanks Andy and Oleg for,
>> *ahem*, dumping all this useful information for us!), GDB will not need
>> modifications in the Linux kernel in this area. In fact, my patch
>> already implements the
[removed people who will be bored]
On Thu, Mar 12, 2015 at 11:08 AM, Oleg Nesterov wrote:
> On 03/12, Andy Lutomirski wrote:
>>
>> On Thu, Mar 12, 2015 at 10:39 AM, Oleg Nesterov wrote:
>> > Well. Speaking of vdso. I understand that unlikely we can do this, but
>> > for uprobes it would be nice
On 03/12, Andy Lutomirski wrote:
>
> On Thu, Mar 12, 2015 at 10:39 AM, Oleg Nesterov wrote:
> > Well. Speaking of vdso. I understand that unlikely we can do this, but
> > for uprobes it would be nice to have a anon-inode file behind this mapping,
> > so that vma_interval_tree_foreach() could
On Thu, Mar 12, 2015 at 11:19 AM, Pedro Alves wrote:
> On 03/12/2015 05:46 PM, Oleg Nesterov wrote:
>> On 03/12, Oleg Nesterov wrote:
>>>
>>> Yes, this is true. OK, lets not dump it.
>>
>> OTOH. We can probably add ->access() into special_mapping_vmops, this
>> way __access_remote_vm() could work
On Thursday, March 12 2015, Oleg Nesterov wrote:
>> Let's wait until my special_mapping vmops rework lands to do that.
>> I'll dust it off and resubmit it.
>
> OK. Please CC me. Not that I think I can help, just I want to understand
> what you are going to do.
If you think your work will impact
On 03/12/2015 05:46 PM, Oleg Nesterov wrote:
> On 03/12, Oleg Nesterov wrote:
>>
>> Yes, this is true. OK, lets not dump it.
>
> OTOH. We can probably add ->access() into special_mapping_vmops, this
> way __access_remote_vm() could work even if gup() fails ?
>
> Jan, Sergio. How much do we want
On 03/12, Andy Lutomirski wrote:
>
> On Thu, Mar 12, 2015 at 10:46 AM, Oleg Nesterov wrote:
> > On 03/12, Oleg Nesterov wrote:
> >>
> >> Yes, this is true. OK, lets not dump it.
> >
> > OTOH. We can probably add ->access() into special_mapping_vmops, this
> > way __access_remote_vm() could work
On 03/12, Sergio Durigan Junior wrote:
>
> On Thursday, March 12 2015, Oleg Nesterov wrote:
>
> >> gdb will still need changes, though, right?
> >
> > This is up to gdb developers. To me, it should simply skip this
> > VM_DONTDUMP vma.
>
> If I understood this discussion correctly (and thanks Andy
On Thu, Mar 12, 2015 at 10:39 AM, Oleg Nesterov wrote:
> On 03/12, Andy Lutomirski wrote:
>>
>> On Thu, Mar 12, 2015 at 9:54 AM, Oleg Nesterov wrote:
>> > On 03/12, Andy Lutomirski wrote:
>> >>
>> > As for 32-bit applications. Yes, this can't work because 32-bit simply
>> > can't access this
On Thu, Mar 12, 2015 at 10:46 AM, Oleg Nesterov wrote:
> On 03/12, Oleg Nesterov wrote:
>>
>> Yes, this is true. OK, lets not dump it.
>
> OTOH. We can probably add ->access() into special_mapping_vmops, this
> way __access_remote_vm() could work even if gup() fails ?
Let's wait until my
On 03/12, Oleg Nesterov wrote:
>
> Yes, this is true. OK, lets not dump it.
OTOH. We can probably add ->access() into special_mapping_vmops, this
way __access_remote_vm() could work even if gup() fails ?
Jan, Sergio. How much do we want do dump this area ? The change above
should be justified.
On Thursday, March 12 2015, Oleg Nesterov wrote:
>> gdb will still need changes, though, right?
>
> This is up to gdb developers. To me, it should simply skip this
> VM_DONTDUMP vma.
If I understood this discussion correctly (and thanks Andy and Oleg for,
*ahem*, dumping all this useful
On 03/12, Andy Lutomirski wrote:
>
> On Thu, Mar 12, 2015 at 9:54 AM, Oleg Nesterov wrote:
> > On 03/12, Andy Lutomirski wrote:
> >>
> > As for 32-bit applications. Yes, this can't work because 32-bit simply
> > can't access this "high" memory. But you know, it would be very nice to
> > have the
On Thu, Mar 12, 2015 at 9:54 AM, Oleg Nesterov wrote:
> On 03/12, Andy Lutomirski wrote:
>>
>> On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov wrote:
>> >
>> > What is not clear: do we really want gup() to fail? Or it is not trivial
>> > to turn __vvar_page into the "normal" page? (to simplify
On 03/12, Andy Lutomirski wrote:
>
> On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov wrote:
> >
> > What is not clear: do we really want gup() to fail? Or it is not trivial
> > to turn __vvar_page into the "normal" page? (to simplify the discussion,
> > lets ignore hpet mapping for now).
>
> We
On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov wrote:
> Add cc's, change subject.
>
> On 03/11, Oleg Nesterov wrote:
>>
>> On 03/05, Jan Kratochvil wrote:
>> >
>> > On Thu, 05 Mar 2015 21:52:56 +0100, Sergio Durigan Junior wrote:
>> > > On Thursday, March 05 2015, Jan Kratochvil wrote:
>> > > >
Add cc's, change subject.
On 03/11, Oleg Nesterov wrote:
>
> On 03/05, Jan Kratochvil wrote:
> >
> > On Thu, 05 Mar 2015 21:52:56 +0100, Sergio Durigan Junior wrote:
> > > On Thursday, March 05 2015, Jan Kratochvil wrote:
> > > > On Thu, 05 Mar 2015 04:48:09 +0100, Sergio Durigan Junior wrote:
>
Add cc's, change subject.
On 03/11, Oleg Nesterov wrote:
On 03/05, Jan Kratochvil wrote:
On Thu, 05 Mar 2015 21:52:56 +0100, Sergio Durigan Junior wrote:
On Thursday, March 05 2015, Jan Kratochvil wrote:
On Thu, 05 Mar 2015 04:48:09 +0100, Sergio Durigan Junior wrote:
Currently
On Thursday, March 12 2015, Oleg Nesterov wrote:
If I understood this discussion correctly (and thanks Andy and Oleg for,
*ahem*, dumping all this useful information for us!), GDB will not need
modifications in the Linux kernel in this area. In fact, my patch
already implements the ignore
On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov o...@redhat.com wrote:
Add cc's, change subject.
On 03/11, Oleg Nesterov wrote:
On 03/05, Jan Kratochvil wrote:
On Thu, 05 Mar 2015 21:52:56 +0100, Sergio Durigan Junior wrote:
On Thursday, March 05 2015, Jan Kratochvil wrote:
On Thu,
On Thursday, March 12 2015, Oleg Nesterov wrote:
gdb will still need changes, though, right?
This is up to gdb developers. To me, it should simply skip this
VM_DONTDUMP vma.
If I understood this discussion correctly (and thanks Andy and Oleg for,
*ahem*, dumping all this useful information
On 03/12, Oleg Nesterov wrote:
Yes, this is true. OK, lets not dump it.
OTOH. We can probably add -access() into special_mapping_vmops, this
way __access_remote_vm() could work even if gup() fails ?
Jan, Sergio. How much do we want do dump this area ? The change above
should be justified.
On 03/12, Andy Lutomirski wrote:
On Thu, Mar 12, 2015 at 9:54 AM, Oleg Nesterov o...@redhat.com wrote:
On 03/12, Andy Lutomirski wrote:
As for 32-bit applications. Yes, this can't work because 32-bit simply
can't access this high memory. But you know, it would be very nice to
have the
On 03/12, Andy Lutomirski wrote:
On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov o...@redhat.com wrote:
What is not clear: do we really want gup() to fail? Or it is not trivial
to turn __vvar_page into the normal page? (to simplify the discussion,
lets ignore hpet mapping for now).
We
On Thu, Mar 12, 2015 at 9:54 AM, Oleg Nesterov o...@redhat.com wrote:
On 03/12, Andy Lutomirski wrote:
On Thu, Mar 12, 2015 at 7:34 AM, Oleg Nesterov o...@redhat.com wrote:
What is not clear: do we really want gup() to fail? Or it is not trivial
to turn __vvar_page into the normal page?
On 03/12/2015 05:46 PM, Oleg Nesterov wrote:
On 03/12, Oleg Nesterov wrote:
Yes, this is true. OK, lets not dump it.
OTOH. We can probably add -access() into special_mapping_vmops, this
way __access_remote_vm() could work even if gup() fails ?
Jan, Sergio. How much do we want do dump
On Thursday, March 12 2015, Oleg Nesterov wrote:
Let's wait until my special_mapping vmops rework lands to do that.
I'll dust it off and resubmit it.
OK. Please CC me. Not that I think I can help, just I want to understand
what you are going to do.
If you think your work will impact the
On Thu, Mar 12, 2015 at 11:19 AM, Pedro Alves pal...@redhat.com wrote:
On 03/12/2015 05:46 PM, Oleg Nesterov wrote:
On 03/12, Oleg Nesterov wrote:
Yes, this is true. OK, lets not dump it.
OTOH. We can probably add -access() into special_mapping_vmops, this
way __access_remote_vm() could
[removed people who will be bored]
On Thu, Mar 12, 2015 at 11:08 AM, Oleg Nesterov o...@redhat.com wrote:
On 03/12, Andy Lutomirski wrote:
On Thu, Mar 12, 2015 at 10:39 AM, Oleg Nesterov o...@redhat.com wrote:
Well. Speaking of vdso. I understand that unlikely we can do this, but
for
On Thu, Mar 12, 2015 at 10:39 AM, Oleg Nesterov o...@redhat.com wrote:
On 03/12, Andy Lutomirski wrote:
On Thu, Mar 12, 2015 at 9:54 AM, Oleg Nesterov o...@redhat.com wrote:
On 03/12, Andy Lutomirski wrote:
As for 32-bit applications. Yes, this can't work because 32-bit simply
can't
On 03/12, Sergio Durigan Junior wrote:
On Thursday, March 12 2015, Oleg Nesterov wrote:
gdb will still need changes, though, right?
This is up to gdb developers. To me, it should simply skip this
VM_DONTDUMP vma.
If I understood this discussion correctly (and thanks Andy and Oleg for,
On Thu, Mar 12, 2015 at 10:46 AM, Oleg Nesterov o...@redhat.com wrote:
On 03/12, Oleg Nesterov wrote:
Yes, this is true. OK, lets not dump it.
OTOH. We can probably add -access() into special_mapping_vmops, this
way __access_remote_vm() could work even if gup() fails ?
Let's wait until my
On 03/12, Andy Lutomirski wrote:
On Thu, Mar 12, 2015 at 10:46 AM, Oleg Nesterov o...@redhat.com wrote:
On 03/12, Oleg Nesterov wrote:
Yes, this is true. OK, lets not dump it.
OTOH. We can probably add -access() into special_mapping_vmops, this
way __access_remote_vm() could work
On 03/12, Andy Lutomirski wrote:
On Thu, Mar 12, 2015 at 10:39 AM, Oleg Nesterov o...@redhat.com wrote:
Well. Speaking of vdso. I understand that unlikely we can do this, but
for uprobes it would be nice to have a anon-inode file behind this mapping,
so that vma_interval_tree_foreach()
52 matches
Mail list logo
