Re: Unresolved probes

[naresh kamboju <naresh dot kernel at gmail dot com>]

Hi,


On Tue, Mar 16, 2010 at 6:05 PM, Steve Dickson <SteveD@redhat.com> wrote:
> Sorry for the delayed response...
>
> On 03/09/2010 11:32 AM, David Smith wrote:
>> On 03/09/2010 07:11 AM, Steve Dickson wrote:
>>> Hello,
>>>
>>> I'm working the testsuite/buildok/nfs* and testsuite/buildok/rpc*
>>> scripts and I'm running across a somewhat familiar problem where
>>> certain routines are not resolvable.
>>>
>>> Using a "normal" 2.6.34 kernel I get the following errors:
>>>
>>> $ sudo ./run-stap -wp4 testsuite/buildok/rpc-all-probes.stp
>>> semantic error: no match while resolving probe point module("sunrpc").function("rpc_new_client").return
>>> semantic error: no match while resolving probe point sunrpc.clnt.create_client.return
>>> semantic error: no match while resolving probe point module("sunrpc").function("rpc_release_task").return
>>> semantic error: no match while resolving probe point sunrpc.sched.release_task.return
>>> Pass 2: analysis failed. ?Try again with another '--vp 01' option.
I have also noticed same build error.
>>>
>>> Now when I use a 2.6.34 kernel compiled with the '-fno-inline-functions-called-once'
>>> flag (which turns off inline-ing when routines are called from only one place)
>>> the run-tap does not fail. And sure enough, both rpc_new_client() and
>>> rpc_release_task() are only called from one place.
>>>
>>> So is there a work-around for this or should I just post the minor
>>> changes I have and move on?
>>
>> I started looking into the same thing the other day. ?I wondered: since
>> those functions are only called from one place, why not just probe the
>> caller? ?In the case of 'rpc_new_client', the caller is 'rpc_create' (in
>> 2.6.34) or 'rpc_create_client' (in 2.6.18)
> In theory this looks like it ?will work but unfortunately the arguments are
> different so the really don't match up very well... Also probing the caller
> in the case of rpc_release_task() does not make sense since the caller
> (i.e. __rpc_execute) is already probed...
>
>>
>> The answer is probably just that the rpc tapset hasn't seen much work
>> since 2007.
> Good point... With this being the case, I'm going to suggest we just patch up
> the rpc.stp with kernel_v clause so it works as it did with older kernels
> and not break with new kernels. In the very near all this code will be
> changing anyway with addition of nfsv4.1 so it probably makes sense to
> patch and move on...
>
> So here is what I would like to do:
>
> commit ee6594700c8e259088bce82aa913cc2e951c7f69
> Author: Steve Dickson <steved@redhat.com>
> Date: ? Tue Mar 16 08:23:14 2010 -0400
>
> ? ?The rpc buildok test suite probe breaks with new kernels
>
> ? ?With newer kernels the rpc_release_task() routine is not defined
> ? ?because it becomes inline since its only called once. Plus the
> ? ?task allocation routines have changed so the arguments no longer
> ? ?match up with previous routines. So this patch uses the kernel_v
> ? ?clauses to allow the original functionality with older kernels
> ? ?and not to break on new kernels.
>
> ? ?Signed-off-by: Steve Dickson <steved@redhat.com>
>
> diff --git a/tapset/rpc.stp b/tapset/rpc.stp
> index d8f2fad..336cfcf 100644
> --- a/tapset/rpc.stp
> +++ b/tapset/rpc.stp
> @@ -121,14 +121,27 @@ probe _sunrpc.clnt.create_client.return.part1 =
> ?{
> ? ? ? ?name = "sunrpc.clnt.create_client.return"
> ?}
> -%)
> -
> ?probe _sunrpc.clnt.create_client.return.part2 =
> ? ? ? ?kernel.function("rpc_new_client").return !,
> ? ? ? ?module("sunrpc").function("rpc_new_client").return
> ?{
> ? ? ? ?name = "sunrpc.clnt.new_client.return"
> ?}
> +%:
> +probe _sunrpc.clnt.create_client.return.part1 =
> + ? ? ? kernel.function("rpc_create").return !,
> + ? ? ? module("sunrpc").function("rpc_create").return
> +{
> + ? ? ? name = "sunrpc.clnt.create_client.return"
> +}
> +probe _sunrpc.clnt.create_client.return.part2 =
> + ? ? ? kernel.function("rpc_create").return !,
> + ? ? ? module("sunrpc").function("rpc_create").return
> +{
> + ? ? ? name = "sunrpc.clnt.create_client.return"
> +}
> +%)
> +
>
> ?/*
> ?* Fires when the RPC client structure is to be cloned
> @@ -722,14 +735,18 @@ probe sunrpc.svc.drop.return = kernel.function("svc_drop").return !,
> ?******************************************************************/
> ?probe sunrpc.sched.entry =
> ? ? ? ?sunrpc.sched.new_task,
> +%( kernel_v <= "2.6.18" %?
> ? ? ? ?sunrpc.sched.release_task,
> +%)
> ? ? ? ?sunrpc.sched.execute,
> ? ? ? ?sunrpc.sched.delay
> ?{}
>
> ?probe sunrpc.sched.return =
> ? ? ? ?sunrpc.sched.new_task.return,
> +%( kernel_v <= "2.6.18" %?
> ? ? ? ?sunrpc.sched.release_task.return,
> +%)
> ? ? ? ?sunrpc.sched.execute.return,
> ? ? ? ?sunrpc.sched.delay.return
> ?{}
> @@ -777,6 +794,7 @@ probe sunrpc.sched.new_task.return = kernel.function("rpc_new_task").return !,
> ?* @prot: ? ? ? ?the IP protocol in the RPC call
> ?* @tk_flags: ? ?the flags of the task
> ?*/
> +%( kernel_v <= "2.6.18" %?
> ?probe sunrpc.sched.release_task = kernel.function("rpc_release_task") !,
> ? ? ? ?module("sunrpc").function("rpc_release_task")
> ?{
> @@ -796,6 +814,7 @@ probe sunrpc.sched.release_task.return =
> ?{
> ? ? ? ?name = "sunrpc.sched.release_task.return"
> ?}
> +%)
>
> ?/*
> ?* Fires when the RPC `scheduler'(or rather, the finite state machine)
>

I have tested on

arch: ARM
kernel: 2.6.29-rt
version: SystemTap-1.0/elfutils 0.143.
glibc: 2.9
gcc version 4.3.3

The above patch is working fine.
Thanks Steve.

Best regards
Naresh Kamboju