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: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Oleg Nesterov <oleg at redhat dot com>
- Cc: Jan Kratochvil <jan dot kratochvil at redhat dot com>, GDB Patches <gdb-patches at sourceware dot org>, Pedro Alves <palves at redhat dot com>
- Date: Thu, 12 Mar 2015 00:30:46 -0400
- 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> <20150311200052 dot GA22654 at redhat dot com>
On Wednesday, March 11 2015, 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.
>> > > ^^^^^^^^^^^^^^
>> > > 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.
Right. As far as I can see this was not being dumped in the previous
code, too. I did not check whether the Linux kernel dumps this or not.
>> 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.
Thanks, Oleg.
For now, I will keep discarding this mapping in the dumping. But please
let us know about your findings.
Meanwhile, I'll keep pinging this patch for reviews here.
--
Sergio
GPG key ID: 0x65FC5E36
Please send encrypted e-mail if possible
http://sergiodj.net/