This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH 1/2] Implement support for checking /proc/PID/coredump_filter


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]