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

[Oleg Nesterov <oleg@redhat.com>]

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.