From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 77025 invoked by alias); 20 Mar 2015 22:02:23 -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 77013 invoked by uid 89); 20 Mar 2015 22:02:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.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; Fri, 20 Mar 2015 22:02:20 +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 (Postfix) with ESMTPS id A2894C4096 for ; Fri, 20 Mar 2015 22:02:19 +0000 (UTC) Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2KM2HCC014454; Fri, 20 Mar 2015 18:02:18 -0400 Message-ID: <550C98E9.1030802@redhat.com> Date: Fri, 20 Mar 2015 22:02:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Sergio Durigan Junior CC: GDB Patches Subject: Re: [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter References: <1426807358-18295-1-git-send-email-sergiodj@redhat.com> <1426807358-18295-2-git-send-email-sergiodj@redhat.com> <550C7118.6080605@redhat.com> <87vbhvwi7x.fsf@redhat.com> In-Reply-To: <87vbhvwi7x.fsf@redhat.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-SW-Source: 2015-03/txt/msg00677.txt.bz2 On 03/20/2015 08:02 PM, Sergio Durigan Junior wrote: >>> >> + It is worth mentioning that, from all those checks described >>> >> + above, the most fragile is the one to see if the file name ends >>> >> + with " (deleted)". This does not necessarily mean that the >>> >> + mapping is anonymous, because the deleted file associated with >>> >> + the mapping may have been a hard link to another file, for >>> >> + example. The Linux kernel checks to see if "i_nlink == 0", but >>> >> + GDB cannot easily do this check. Therefore, we made a compromise >> > >> > Cannot do it easily, or cannot do it at all? > It cannot do it easily. If GDB is run by root, then it could (in > theory) inspect the contents of /proc/PID/map_files and determine > whether the " (deleted)" file was a hard link or not. Ah, could you include that in the comment please? Otherwise every time I read that I'll wonder what wasn't easy. :-) Like: "(..) example. The Linux kernel checks to see if "i_nlink == 0", but GDB cannot easily (and normally) do this check (iff running as root, it could find the mapping in /proc/PID/map_files/ and determine whether there still are other hard links to the inode/file). Therefore, we made a compromise (...)" I quickly tried something like that with "/proc/pid/fd/*", and unfortunately the link count is always 1, at least on F20's kernel: $ tail > a& [1] 12343 [1]+ Stopped tail > a $ ls -l a -rw-rw-r--. 1 pedro pedro 0 Mar 20 21:29 a $ ln a b $ ls -l a -rw-rw-r--. 2 pedro pedro 0 Mar 20 21:29 a $ ls -l /proc/12343/fd/1 l-wx------. 1 pedro pedro 64 Mar 20 21:30 /proc/12343/fd/1 -> /tmp/a If map_files/ works the same, I think we'd have to get the file's inode number, and look over the whole filesystem for other files with that inode number (the equivalent of 'ls -i' 'find / -inum'). Urgh! Anyway, with the comment tweak, the patch looks good to me. Thanks again for doing this. Thanks, Pedro Alves