Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902)

[Sergio Durigan Junior <sergiodj@redhat.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/