From mboxrd@z Thu Jan 1 00:00:00 1970 From: "J. Bruce Fields" Subject: Re: Getting PIDs out of inodes? Date: Thu, 16 Jan 2014 14:02:55 -0500 Message-ID: <20140116190255.GA19196@fieldses.org> References: <20140116044414.GV10323@ZenIV.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Al Viro , linux-fsdevel@vger.kernel.org To: Ismael =?utf-8?Q?Farf=C3=A1n?= Return-path: Received: from fieldses.org ([174.143.236.118]:59741 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750937AbaAPTC4 (ORCPT ); Thu, 16 Jan 2014 14:02:56 -0500 Content-Disposition: inline In-Reply-To: Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Thu, Jan 16, 2014 at 10:14:42AM -0600, Ismael Farf=C3=A1n 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 mus= tn't > >> talk ill of the dead, but they are my prime suspects because of th= is > >> (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 g= et > >> the struct file (which contains a PID) out of the inode. > > > > That makes no sense. struct file does *not* contain a PID. > > >=20 > This comment in struct file fooled me then :/ > int f_owner; /* pid or -pgrp where SIGIO should be sent */ >=20 > >> I don't know if it's possible to script an iteration with crash ov= er > >> 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 !=3D 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 y= ou actually > > trying to do? Details, please... >=20 > I have some inodes open such that they don't show with fuser... >=20 > 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! >> >=20 > Because of those guys I can't umount the FS (hence there's a bug!) >=20 > I'm trying to figure out what command, daemon, *kernel thread*, PID, > unicorn... created or left them there. >=20 > 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 ... >=20 >=20 > 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