This is the mail archive of the
mailing list for the GDB project.
vvar, gup && coredump
- From: Oleg Nesterov <oleg at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>, Andy Lutomirski <luto at amacapital dot net>
- Cc: Sergio Durigan Junior <sergiodj at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>, linux-kernel at vger dot kernel dot org
- Date: Thu, 12 Mar 2015 15:34:39 +0100
- Subject: vvar, gup && coredump
- Authentication-results: sourceware.org; auth=none
- References: <878ufc9kau dot fsf at redhat dot com> <20150305154827 dot GA9441 at host1 dot jankratochvil dot net> <87zj7r5fpz dot fsf at redhat dot com> <20150305205744 dot GA13165 at host1 dot jankratochvil dot net> <20150311200052 dot GA22654 at redhat dot com>
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 it also tries to dump [vvar] (by default rules) but that is
> > > > unreadable for some reason, causing:
> > > > warning: Memory read failed for corefile section, 8192 bytes at 0x7ffff6ceb000.
> > > > ^^^^^^^^^^^^^^
> > It would be good to get a reply from a kernel aware person what does it mean
> > before such patch gets accepted. It can be also just a Linux kernel bug.
> _So far_ this doesn't look like a kernel bug to me.
> But! I need to recheck. In fact, it seems to me that I should discuss
> this on lkml. I have some concerns, but most probably this is only my
> misunderstanding, I need to read this (new to me) code more carefully.
Hi Andy, we need your help ;)
So, the problem is that gdb can't access the "vvar" mapping which looks
like the "normal" vma from user-space pov.
Technically this is clear. vvar_mapping->pages is the "dummy" no_pages
array, get_user_pages() can't succeed. In fact even follow_page() can't
work because of VM_PFNMAP/_PAGE_SPECIAL set by remap_pfn_range().
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).
Because this doesn't look consistent. gdb tries to "coredump" the live
process like the kernel does, but fails to dump the "r--p ... [vvar]"
OK, gdb can look at VM_DONTDUMP bit in "VmFlags:" field in /proc/pid/smaps
and skip this vma. But, why (afaics) the kernel dumps this vma then? Lets
look at vma_dump_size(),
/* always dump the vdso and vsyscall sections */
if (vma->vm_flags & VM_DONTDUMP)
so the kernel ignores VM_DONTDUMP in this case, always_dump_vma() returns
true because of special_mapping_name(). Perhaps we should check VM_DONTDUMP
before always_dump_vma() ?
Or. We can teach gdb to read and dump its own "vvar" mapping to mimic the
kernel behaviour, this is the same read-only memory. But this hack doesn't
look nice, gdb should not know "too much" about the kernel internals.