public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Pedro Alves <palves@redhat.com>
To: Sergio Durigan Junior <sergiodj@redhat.com>
Cc: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter
Date: Fri, 20 Mar 2015 22:02:00 -0000	[thread overview]
Message-ID: <550C98E9.1030802@redhat.com> (raw)
In-Reply-To: <87vbhvwi7x.fsf@redhat.com>

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

  reply	other threads:[~2015-03-20 22:02 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-19 23:22 [PATCH v4 0/2] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) Sergio Durigan Junior
2015-03-19 23:22 ` [PATCH 2/2] Documentation and testcase Sergio Durigan Junior
2015-03-20 19:46   ` Pedro Alves
2015-03-20 21:03     ` Sergio Durigan Junior
2015-03-20 22:09       ` Pedro Alves
2015-03-22 20:46         ` Sergio Durigan Junior
2015-03-23 20:27           ` Pedro Alves
2015-03-23 21:08             ` Sergio Durigan Junior
2015-03-23 23:06               ` Pedro Alves
2015-03-24  6:37                 ` Sergio Durigan Junior
2015-03-24 10:12                   ` Pedro Alves
2015-03-24 23:15                     ` Sergio Durigan Junior
2015-03-24 23:48                       ` Pedro Alves
2015-03-19 23:22 ` [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter Sergio Durigan Junior
2015-03-20 19:12   ` Pedro Alves
2015-03-20 20:02     ` Sergio Durigan Junior
2015-03-20 22:02       ` Pedro Alves [this message]
2015-03-23 18:40         ` Sergio Durigan Junior
2015-03-23 20:36           ` Pedro Alves
2015-03-24 23:57 [PATCH v4 0/2] Improve corefile generation by using /proc/PID/coredump_filter (PR corefile/16902) Sergio Durigan Junior
2015-03-24 23:57 ` [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter Sergio Durigan Junior
2015-03-27  9:53   ` Pedro Alves
2015-03-31 23:40     ` Sergio Durigan Junior

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=550C98E9.1030802@redhat.com \
    --to=palves@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=sergiodj@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).