You might want to look the inode's information using either the struct 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 of 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 data. But in your case, the above commands should work and you can be able to retrieve some information from it. The same works for dentry, super_block, vfsmount structures or any other 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 symbols to the crash session you're using (if the module is not built-in compiled.) Something like that: crash> mod -s ext4 <foo/bar/linux/fs/ext4/ext4.ko.debug 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 for me in some cases when tracking down bugs. Just my 2 cents. On Fri, Jan 10, 2014 at 11:35:19AM -0600, Ismael Farfán 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: 1111111111111111100010000000100100110110010000011001100100000000 > 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 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 -- Carlos -- 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
