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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html