dtrace discuss - Jun 2008 - function names of kerrnel modules not printed

Greetings,

I tried to catch the place in my kernel module (actually, a socket 
module) from where kmem_[z]alloc() is called with a zero length 
parameter. Using the script below, this basically works:

#!/usr/sbin/dtrace -s

fbt::kmem_alloc:entry
/arg0 == 0/
{
    stack();
}

fbt::kmem_zalloc:entry
/arg0 == 0/
{
    stack();
}

However, the printout does not show the function names of my module:
root at d1 # ./kmem_alloc_zerolen.d
dtrace: script ''./kmem_alloc_zerolen.d'' matched 2 probes
CPU     ID                    FUNCTION:NAME
   1  12069                 kmem_alloc:entry
               0xfffffffff86ca627
               0xfffffffff86b825b
               0xfffffffff86ad139
               sockfs`socket_ioctl+0x2a
               sockfs`socket_vop_ioctl+0x57
               genunix`fop_ioctl+0x7b
               genunix`ioctl+0x174
               unix`sys_syscall+0x272

Notes that may or may not be relevant:
- I have post-processed my module to contain CTF information.
- The topmost function in my module is called via a function ptr (socket 
ops ptr)
- The socket modules are loaded when I open the socket, and unloaded 
right when it''s closed - maybe a race when mapping the addresses to the
symbol table?
- Function names where printed fine for others of our modules I dtraced 
before.

  thanks for hints, Joachim

-- 
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com

Joachim Worringen wrote:
> However, the printout does not show the function names of my module:
> root at d1 # ./kmem_alloc_zerolen.d
> dtrace: script ''./kmem_alloc_zerolen.d'' matched 2 probes
> CPU     ID                    FUNCTION:NAME
>    1  12069                 kmem_alloc:entry
>                0xfffffffff86ca627
>                0xfffffffff86b825b
>                0xfffffffff86ad139
>                sockfs`socket_ioctl+0x2a
>                sockfs`socket_vop_ioctl+0x57
>                genunix`fop_ioctl+0x7b
>                genunix`ioctl+0x174
>                unix`sys_syscall+0x272
> 
> Notes that may or may not be relevant:
> - I have post-processed my module to contain CTF information.
> - The topmost function in my module is called via a function ptr (socket 
> ops ptr)
> - The socket modules are loaded when I open the socket, and unloaded 
> right when it''s closed - maybe a race when mapping the addresses
to the
> symbol table?
just a guess:
I think you may be seeing an effect of the unloading: while the stack is 
recorded synchronously (obviously ;-), the mapping to symbolic names 
happens at a later time; if your module is gone by then, there''s
nothing
to map.
Can you disable the unloading for test purposes and see what happens?

HTH
Michael
-- 
Michael Schuster 	http://blogs.sun.com/recursion
Recursion, n.: see ''Recursion''

Michael Schuster wrote:
> Joachim Worringen wrote:
> 
>> However, the printout does not show the function names of my module:
>> root at d1 # ./kmem_alloc_zerolen.d
>> dtrace: script ''./kmem_alloc_zerolen.d'' matched 2
probes
>> CPU     ID                    FUNCTION:NAME
>>    1  12069                 kmem_alloc:entry
>>                0xfffffffff86ca627
>>                0xfffffffff86b825b
>>                0xfffffffff86ad139
>>                sockfs`socket_ioctl+0x2a
>>                sockfs`socket_vop_ioctl+0x57
>>                genunix`fop_ioctl+0x7b
>>                genunix`ioctl+0x174
>>                unix`sys_syscall+0x272
>>
>> Notes that may or may not be relevant:
>> - I have post-processed my module to contain CTF information.
>> - The topmost function in my module is called via a function ptr 
>> (socket ops ptr)
>> - The socket modules are loaded when I open the socket, and unloaded 
>> right when it''s closed - maybe a race when mapping the
addresses to
>> the symbol table?
> 
> just a guess:
> I think you may be seeing an effect of the unloading: while the stack is 
> recorded synchronously (obviously ;-), the mapping to symbolic names 
> happens at a later time; if your module is gone by then, there''s
nothing
> to map.
> Can you disable the unloading for test purposes and see what happens?
Could have done it before as I already thought in this direction...

Did so (by keeping one socket open), and now it works:

root at d1 # ./kmem_alloc_zerolen.d
dtrace: script ''./kmem_alloc_zerolen.d'' matched 2 probes
CPU     ID                    FUNCTION:NAME
   1  12069                 kmem_alloc:entry
               dis_ssocks`osif_malloc+0x57
               dis_ssocks`AF_SCI_raw_ioctl+0xa5f
               dis_ssocks`ssocks_raw_ioctl+0x9
               sockfs`socket_ioctl+0x2a
               sockfs`socket_vop_ioctl+0x57
               genunix`fop_ioctl+0x7b
               genunix`ioctl+0x174
               unix`sys_syscall+0x272

Thanks, Joachim

-- 
Joachim Worringen, Software Architect, Dolphin Interconnect Solutions
phone ++49/(0)228/324 08 17 - http://www.dolphinics.com