From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38075 invoked by alias); 13 Mar 2015 04:50:54 -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 38064 invoked by uid 89); 13 Mar 2015 04:50:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 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; Fri, 13 Mar 2015 04:50:52 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2D4on53023268 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Fri, 13 Mar 2015 00:50:49 -0400 Received: from localhost (dhcp-10-15-16-169.yyz.redhat.com [10.15.16.169]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2D4omdG020085 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Fri, 13 Mar 2015 00:50:49 -0400 From: Sergio Durigan Junior To: Oleg Nesterov Cc: Andy Lutomirski , Jan Kratochvil , GDB Patches , Pedro Alves , "linux-kernel\@vger.kernel.org" Subject: Re: vvar, gup && coredump References: <20150305154827.GA9441@host1.jankratochvil.net> <87zj7r5fpz.fsf@redhat.com> <20150305205744.GA13165@host1.jankratochvil.net> <20150311200052.GA22654@redhat.com> <20150312143438.GA4338@redhat.com> <20150312165423.GA10073@redhat.com> <20150312173901.GA12225@redhat.com> <874mpqp0sm.fsf@redhat.com> <20150312180229.GA13711@redhat.com> X-URL: http://blog.sergiodj.net Date: Fri, 13 Mar 2015 04:50:00 -0000 Message-ID: <87zj7hlcuv.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg00387.txt.bz2 On Thursday, March 12 2015, Oleg Nesterov wrote: >> If I understood this discussion correctly (and thanks Andy and Oleg for, >> *ahem*, dumping all this useful information for us!), GDB will not need >> modifications in the Linux kernel in this area. In fact, my patch >> already implements the "ignore VM_DONTDUMP mappings" part, so we're >> pretty much covered. > > OK, thanks. > > And it seems that we all agree that the kernel should not dump this vma > too. Could you confirm that this is fine from gdb pov just in case? Yes, this is what we expect from the GDB side. This mapping is marked as "dd", so it does not make sense to dump it. While I have you guys, would it be possible for the Linux kernel to include a new flag on VmFlags to uniquely identify an anonymous mapping? Currently, there is no easy way to do that from userspace. My patch implements the following heuristic on GDB: if (pathname == "/dev/zero (deleted)" || pathname == "/SYSV%08x (deleted)" || pathname == " (deleted)" || "Anonymous:" field is > 0 kB || "AnonHugePages:" field is > 0 kB) mapping is anonymous; However, this can be fragile. The Linux kernel checks for i_nlink == 0, but there is no easy way for GDB to check this on userspace (as Jan mentioned, one could look at /proc/PID/map_files/, but they are only accessible by root). That's why I think it would be good to provide this info right away in /proc/PID/smaps... Thanks, -- Sergio GPG key ID: 0x65FC5E36 Please send encrypted e-mail if possible http://sergiodj.net/