Re: Help exploring an orphan FD

["Ismael Farfán" <sulfurfff@gmail.com>]

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@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



-- 
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