This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)
- From: Oleg Nesterov <oleg at redhat dot com>
- To: Jan Kratochvil <jan dot kratochvil at redhat dot com>
- Cc: Sergio Durigan Junior <sergiodj at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>
- Date: Wed, 11 Mar 2015 21:00:52 +0100
- Subject: Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)
- 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>
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.
> > > ^^^^^^^^^^^^^^
> > > Saved corefile /tmp/1j
> > > (gdb) _
> > > # grep 7ffff6ceb000 /proc/$p/maps
> > > 7ffff6ceb000-7ffff6ced000 r--p 00000000 00:00 0 [vvar]
> > > ^^^^^^^^^^^^ ^^^^
> > >
> > > I do not know what [vvar] is good for and why it cannot be read.
Well, I am not sure I understand this new mapping correctly. I need to
recheck.
But apparently it represents the kernel data (say, gtod) which vdso code
(running in user mode) can read.
Probably gdb doesn't need to dump this vma, but see below.
> 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.
I guess it fails because of
struct page *no_pages[] = {NULL};
struct vm_special_mapping vvar_mapping = {
.name = "[vvar]",
.pages = no_pages,
};
so get_user_pages() -> special_mapping_fault() can't succeed, there is
no page it could return.
And the code above looks as if we deny the access on purpose. Probably
this makes sense, this section can contain the "sensitive" data, say,
hpet timer's io memory...
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.
Oleg.