This is the mail archive of the systemtap@sourceware.org mailing list for the systemtap project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Unresolved probes


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]