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
next prev parent 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).