Re: new static user probe types

[Stan Cox <scox at redhat dot com>]

Josh Stone wrote:
> On 07/15/2009 09:19 AM, Stan Cox wrote:
>   
>
> task_tid(task_current()) == tid(), and the latter should be faster.  But
> anyway, it's not clear to me what this is guarding against.
>
>   
An application sets up a kprobe probe by hijacking a syscall, currently 
SYS_getegid, and passing the tid.  On the stap side the .mark probe gets 
converted to kernel.function("sys_getegid") so the guard wants to make 
certain we didn't get here via another task doing a SYS_getegid syscall.
> Beware that the 1953719668 constant is little-endian specific.
>
> I'm also nervous about saving _stp_probe_name_XXX -- murphy's law may
> eventually produce a mark in one app that happens to have the same
> pointer address as a different mark in a different app.
>   
There will be a series of probes for the hijacked syscall, one per 
marker type.  So if this is postgres there would be one for 
transaction__start, lwlock__acquire, etc.  So it is necessary to check 
that the probe for transaction__start actually arrived here from a 
transaction__start.  The probe name is passed in so the easy way to do 
this is to compare the passed in probe name to the .mark("marker_name") 
and check that they match.  However it would be nice to "optimize" this 
so the string comparison is avoided if there is a lower cost 
alternative.  That is what my experiment was trying to achieve. Any 
clever suggestions on how to do that?