From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 117570 invoked by alias); 11 Mar 2015 20:02:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 117555 invoked by uid 89); 11 Mar 2015 20:02:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.0 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Wed, 11 Mar 2015 20:02:40 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2BK2d9u029354 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Wed, 11 Mar 2015 16:02:39 -0400 Received: from tranklukator.brq.redhat.com (dhcp-1-208.brq.redhat.com [10.34.1.208]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with SMTP id t2BK2b2X017225; Wed, 11 Mar 2015 16:02:38 -0400 Received: by tranklukator.brq.redhat.com (nbSMTP-1.00) for uid 500 oleg@redhat.com; Wed, 11 Mar 2015 21:00:53 +0100 (CET) Date: Wed, 11 Mar 2015 20:02:00 -0000 From: Oleg Nesterov To: Jan Kratochvil Cc: Sergio Durigan Junior , GDB Patches , Pedro Alves Subject: Re: [PATCH] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) Message-ID: <20150311200052.GA22654@redhat.com> References: <878ufc9kau.fsf@redhat.com> <20150305154827.GA9441@host1.jankratochvil.net> <87zj7r5fpz.fsf@redhat.com> <20150305205744.GA13165@host1.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20150305205744.GA13165@host1.jankratochvil.net> User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2015-03/txt/msg00319.txt.bz2 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.