2014/1/10 Carlos Maiolino > 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 Thanks Carlos That should keep me entertained for a while :) Cheers 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
