From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?UTF-8?Q?Ismael_Farf=C3=A1n?= Subject: Re: Help exploring an orphan FD Date: Fri, 10 Jan 2014 12:29:18 -0600 Message-ID: References: <20140110174911.GA14661@orion.maiolino.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: linux-fsdevel@vger.kernel.org To: Carlos Maiolino Return-path: Received: from mail-wg0-f44.google.com ([74.125.82.44]:54318 "EHLO mail-wg0-f44.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750911AbaAJS3T convert rfc822-to-8bit (ORCPT ); Fri, 10 Jan 2014 13:29:19 -0500 Received: by mail-wg0-f44.google.com with SMTP id l18so3545947wgh.35 for ; Fri, 10 Jan 2014 10:29:18 -0800 (PST) In-Reply-To: <20140110174911.GA14661@orion.maiolino.org> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: 2014/1/10 Carlos Maiolino > You might want to look the inode's information using either the struc= t command > or just inode itself (depending of your crash version, it should work= ), pointing > the inode address you're referring to. > > So, either: > > crash> struct inode ffff8808d17c5518 > or just > crash> inode ffff8808d17c5518 > > Bear in mind that crash will only take the address as the beginning o= f the > structure and split the data according with the structure definition.= If for > some reason you pass to it a wrong offset, you might get not useful d= ata. But in > your case, the above commands should work and you can be able to retr= ieve some > information from it. > > The same works for dentry, super_block, vfsmount structures or any ot= her > structure. > Pay attention only if you're using modules specific structures, like = for example > ext4_sb_info. In such cases, you will need to load the module debug s= ymbols to > the crash session you're using (if the module is not built-in compile= d.) > > Something like that: > crash> mod -s ext4 > Another command you might find useful is the `struct -o`, it uses to = be very > useful when you need to calculate offsets of a specific structure. > > crash> struct -o inode > > ^ this, will bring you the inode structure definition and the offset = of each > field. I often use if when disassembling a function call, and see for= example > something like: > > mov %eax[0x18] %rdi > > So, looking what's 0x18 offset inside an structure is really useful f= or me in > some cases when tracking down bugs. > > > Just my 2 cents. > > On Fri, Jan 10, 2014 at 11:35:19AM -0600, Ismael Farf=C3=A1n wrote: >> Hello guys >> >> Analyzing a crash dump I noticed some orphan / suspicious open file = descriptors: >> >> 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 foo.txt >> >> >> >> Does anyone knows how to turn those addresses into something useful? >> I already tried some of the commands that looked like could do >> something... but no good. >> >> crash> eval ffff880936419900 >> hexadecimal: ffff880936419900 >> decimal: 18446612171879192832 (-131901830358784) >> octal: 1777774200446620314400 >> binary: 1111111111111111100010000000100100110110010000011001100= 100000000 >> crash> extend ffff880936419900 >> extend: ffff880936419900: No such device or address >> crash> struct ffff8808d17c5518 >> struct: invalid data structure reference: ffff8808d17c5518 >> >> >> >> I was hopping to get something like when I type "inode" but with >> values in the fields. >> >> I'm just learning to use crash... and I'm not sure if to expect a >> struct inode there. Also in the documentation it doesn't specifies >> whether "address" means "in memory" or "in disk". >> http://www.tldp.org/LDP/tlk/ds/ds.html >> http://people.redhat.com/anderson/crash_whitepaper/help_pages/mount.= html >> >> >> Any ideas? >> Ismael >> >> >> >> -- >> Do not let me induce you to satisfy my curiosity, from an expectatio= n, >> 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-fsde= vel" in >> the body of a message to majordomo@vger.kernel.org >> More majordomo info at http://vger.kernel.org/majordomo-info.html > > -- > Carlos Thanks Carlos That should keep me entertained for a while :) Cheers Ismael --=20 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html