Help exploring an orphan FD

Help exploring an orphan FD

[Ismael Farfán]

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.

Re: Help exploring an orphan FD

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

Re: Help exploring an orphan FD

[Ismael Farfán]

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