Getting PIDs out of inodes?

Getting PIDs out of inodes?

[Ismael Farfán]

Hello list.

I'm struggling with a problem involving some orphan descriptors I
found in a crash dump.

I'd like to know who created or inherited (as in fork) them. I mustn't
talk ill of the dead, but they are my prime suspects because of this
(doesn't shows with ps):
[49886.362859] umount.nfs[8425]: segfault at 19... bla bla

Given what I read[1,2], there doesn't seem to be a direct way to get
the struct file (which contains a PID) out of the inode.

--crash dump--
    |
    v
struct inode     <-- this is what I have!
     ^
     |
struct file <--> next/prev file, PID I want (probably)
     ^
     |
struct files_struct
    ^
    |
struct task_struct


I don't know if it's possible to script an iteration with crash over
all tasks in search of a particular inode.
     DENTRY           INODE       TYPE PATH
ffff880936419900 ffff8808d17c5518 REG  foo.txt

Any ideas on how to know who created the file descriptors?

Cheers
Ismael



[1] http://www.tldp.org/LDP/tlk/ds/ds.html
[2] http://www.tldp.org/LDP/tlk/kernel/processes.html


-- 
Do not let me induce you to satisfy my curiosity, from an expectation,
that I shall gratify yours. What I may judge proper to conceal, does
not concern myself alone.

Re: Getting PIDs out of inodes?

[Al Viro]

On Wed, Jan 15, 2014 at 04:08:01PM -0600, Ismael Farf??n wrote:
> Hello list.
> 
> I'm struggling with a problem involving some orphan descriptors I
> found in a crash dump.
> 
> I'd like to know who created or inherited (as in fork) them. I mustn't
> talk ill of the dead, but they are my prime suspects because of this
> (doesn't shows with ps):
> [49886.362859] umount.nfs[8425]: segfault at 19... bla bla
> 
> Given what I read[1,2], there doesn't seem to be a direct way to get
> the struct file (which contains a PID) out of the inode.

That makes no sense.  struct file does *not* contain a PID.

> I don't know if it's possible to script an iteration with crash over
> all tasks in search of a particular inode.
>      DENTRY           INODE       TYPE PATH
> ffff880936419900 ffff8808d17c5518 REG  foo.txt
> 
> Any ideas on how to know who created the file descriptors?

... and descriptor != struct file.  Moreover, if "who?" is "which process?",
it might have been dead, buried and its PID reused a long time ago - opened
file can easily outlive the process that had opened it.  What are you actually
trying to do?  Details, please...

Re: Getting PIDs out of inodes?

[Ismael Farfán]

2014/1/15 Al Viro :
> On Wed, Jan 15, 2014 at 04:08:01PM -0600, Ismael Farf??n wrote:
>>
>> I'd like to know who created or inherited (as in fork) them. I mustn't
>> talk ill of the dead, but they are my prime suspects because of this
>> (doesn't shows with ps):
>> [49886.362859] umount.nfs[8425]: segfault at 19... bla bla
>>
>> Given what I read[1,2], there doesn't seem to be a direct way to get
>> the struct file (which contains a PID) out of the inode.
>
> That makes no sense.  struct file does *not* contain a PID.
>

This comment in struct file fooled me then :/
int f_owner; /* pid or -pgrp where SIGIO should be sent */

>> I don't know if it's possible to script an iteration with crash over
>> all tasks in search of a particular inode.
>>      DENTRY           INODE       TYPE PATH
>> ffff880936419900 ffff8808d17c5518 REG  foo.txt
>>
>> Any ideas on how to know who created the file descriptors?
>
> ... and descriptor != struct file.  Moreover, if "who?" is "which process?",
> it might have been dead, buried and its PID reused a long time ago - opened
> file can easily outlive the process that had opened it.  What are you actually
> trying to do?  Details, please...

I have some inodes open such that they don't show with fuser...

crash> fuser /mnt
No users of /mnt
crash> mount -f /dev/sdb1
VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME
ffff88094c4cc680 ffff880946018c00 myfs /dev/sdb1 /mnt
OPEN FILES
DENTRY INODE TYPE PATH
ffff880936419900 ffff8808d17c5518 REG foo1.txt
ffff8809270079c0 ffff880927150618 REG foo2.txt
<< and another 26 of them! >>

Because of those guys I can't umount the FS (hence there's a bug!)

I'm trying to figure out what command, daemon, *kernel thread*, PID,
unicorn... created or left them there.

Even if the PID was reused (unlikely because the system ran only 18
hours) I can try to match it in other logs. For instance, my prime
suspect is NFS, but I *can't* blame it only with this as proof (from
dmesg) :
[45249.452255] umount.nfs[30037]: segfault at 19 ip ...


I'm trying to solve it and learn crash at the same time :)

Cheers


-- 
Do not let me induce you to satisfy my curiosity, from an expectation,
that I shall gratify yours. What I may judge proper to conceal, does
not concern myself alone.

Re: Getting PIDs out of inodes?

[J. Bruce Fields]

On Thu, Jan 16, 2014 at 10:14:42AM -0600, Ismael Farfán wrote:
> 2014/1/15 Al Viro :
> > On Wed, Jan 15, 2014 at 04:08:01PM -0600, Ismael Farf??n wrote:
> >>
> >> I'd like to know who created or inherited (as in fork) them. I mustn't
> >> talk ill of the dead, but they are my prime suspects because of this
> >> (doesn't shows with ps):
> >> [49886.362859] umount.nfs[8425]: segfault at 19... bla bla
> >>
> >> Given what I read[1,2], there doesn't seem to be a direct way to get
> >> the struct file (which contains a PID) out of the inode.
> >
> > That makes no sense.  struct file does *not* contain a PID.
> >
> 
> This comment in struct file fooled me then :/
> int f_owner; /* pid or -pgrp where SIGIO should be sent */
> 
> >> I don't know if it's possible to script an iteration with crash over
> >> all tasks in search of a particular inode.
> >>      DENTRY           INODE       TYPE PATH
> >> ffff880936419900 ffff8808d17c5518 REG  foo.txt
> >>
> >> Any ideas on how to know who created the file descriptors?
> >
> > ... and descriptor != struct file.  Moreover, if "who?" is "which process?",
> > it might have been dead, buried and its PID reused a long time ago - opened
> > file can easily outlive the process that had opened it.  What are you actually
> > trying to do?  Details, please...
> 
> I have some inodes open such that they don't show with fuser...
> 
> crash> fuser /mnt
> No users of /mnt
> crash> mount -f /dev/sdb1
> VFSMOUNT SUPERBLK TYPE DEVNAME DIRNAME
> ffff88094c4cc680 ffff880946018c00 myfs /dev/sdb1 /mnt
> OPEN FILES
> DENTRY INODE TYPE PATH
> ffff880936419900 ffff8808d17c5518 REG foo1.txt
> ffff8809270079c0 ffff880927150618 REG foo2.txt
> << and another 26 of them! >>
> 
> Because of those guys I can't umount the FS (hence there's a bug!)
> 
> I'm trying to figure out what command, daemon, *kernel thread*, PID,
> unicorn... created or left them there.
> 
> Even if the PID was reused (unlikely because the system ran only 18
> hours) I can try to match it in other logs. For instance, my prime
> suspect is NFS, but I *can't* blame it only with this as proof (from
> dmesg) :
> [45249.452255] umount.nfs[30037]: segfault at 19 ip ...
> 
> 
> I'm trying to solve it and learn crash at the same time :)

Best is probably to report the details (with kernel versions, etc.) to
linux-nfs@vger.kernel.org.

--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html