pfaults.stp fix (for 2.6.13 and beyond)

pfaults.stp fix (for 2.6.13 and beyond)

[Badari Pulavarty]

[-- Attachment #1: Type: text/plain, Size: 501 bytes --]

Hi,

handle_mm_fault() became a inline function now (2.6.13 & beyond). 
So pfaults.stp should use __handle_mm_fault() instead.

Thanks,
Badari

[root@elm3b23 systemtap.samples]# stap -g pfaults.stp
semantic error: no match for probe point
         while: resolving probe point kernel.function("handle_mm_fault")
semantic error: no match for probe point
         while: resolving probe point kernel.function
("handle_mm_fault").return
Pass 2: analysis failed.  Try again with '-v' (verbose) option.




[-- Attachment #2: pfaults.patch --]
[-- Type: text/x-patch, Size: 818 bytes --]

--- tests/testsuite/systemtap.samples/pfaults.stp	2005-10-05 08:13:29.000000000 -0700
+++ tests.new/testsuite/systemtap.samples/pfaults.stp	2005-10-05 08:11:27.000000000 -0700
@@ -2,7 +2,7 @@
 
 global pidnames, faults, fault_types
 
-probe kernel.function("handle_mm_fault") {
+probe kernel.function("__handle_mm_fault") {
 
    # Maintain a pid-to-execname mapping.  This logic should get transplanted
    # into a tapset script that is automatically included upon reference to
@@ -15,7 +15,7 @@ probe kernel.function("handle_mm_fault")
 # (needed only until bug 1132 supports $retvalue)
 function get_retvalue:long () %{ THIS->__retvalue = fetch_register(0); %}
 
-probe kernel.function("handle_mm_fault").return {
+probe kernel.function("__handle_mm_fault").return {
   fault_types [pid(), get_retvalue()] ++
 }
 

Re: pfaults.stp fix (for 2.6.13 and beyond)

[William Cohen]

Badari Pulavarty wrote:
> Hi,
> 
> handle_mm_fault() became a inline function now (2.6.13 & beyond). 
> So pfaults.stp should use __handle_mm_fault() instead.
> 
> Thanks,
> Badari
> 
> [root@elm3b23 systemtap.samples]# stap -g pfaults.stp
> semantic error: no match for probe point
>          while: resolving probe point kernel.function("handle_mm_fault")
> semantic error: no match for probe point
>          while: resolving probe point kernel.function
> ("handle_mm_fault").return
> Pass 2: analysis failed.  Try again with '-v' (verbose) option.

The number for the various types of faults will also need to be 
adjusted. Looking at 2.6.13-1.1526 kernel used in FC4.

linux-2.6.13/include/linux/mm.h has:

#define VM_FAULT_OOM    0x00
#define VM_FAULT_SIGBUS 0x01
#define VM_FAULT_MINOR  0x02
#define VM_FAULT_MAJOR  0x03

I noticed this because of the large number of major faults without any 
minor faults recorded. However, using the numbers above I see values 
that look more reasonable for minor faults, but I don't see any major 
faults counted when I was playing around with this.

-Will

> 
> 
> 
> 
> 
> ------------------------------------------------------------------------
> 
> --- tests/testsuite/systemtap.samples/pfaults.stp	2005-10-05 08:13:29.000000000 -0700
> +++ tests.new/testsuite/systemtap.samples/pfaults.stp	2005-10-05 08:11:27.000000000 -0700
> @@ -2,7 +2,7 @@
>  
>  global pidnames, faults, fault_types
>  
> -probe kernel.function("handle_mm_fault") {
> +probe kernel.function("__handle_mm_fault") {
>  
>     # Maintain a pid-to-execname mapping.  This logic should get transplanted
>     # into a tapset script that is automatically included upon reference to
> @@ -15,7 +15,7 @@ probe kernel.function("handle_mm_fault")
>  # (needed only until bug 1132 supports $retvalue)
>  function get_retvalue:long () %{ THIS->__retvalue = fetch_register(0); %}
>  
> -probe kernel.function("handle_mm_fault").return {
> +probe kernel.function("__handle_mm_fault").return {
>    fault_types [pid(), get_retvalue()] ++
>  }
>  

Re: pfaults.stp fix (for 2.6.13 and beyond)

[Badari Pulavarty]

On Wed, 2005-10-05 at 12:15 -0400, William Cohen wrote:
> Badari Pulavarty wrote:
> > Hi,
> > 
> > handle_mm_fault() became a inline function now (2.6.13 & beyond). 
> > So pfaults.stp should use __handle_mm_fault() instead.
> > 
> > Thanks,
> > Badari
> > 
> > [root@elm3b23 systemtap.samples]# stap -g pfaults.stp
> > semantic error: no match for probe point
> >          while: resolving probe point kernel.function("handle_mm_fault")
> > semantic error: no match for probe point
> >          while: resolving probe point kernel.function
> > ("handle_mm_fault").return
> > Pass 2: analysis failed.  Try again with '-v' (verbose) option.
> 
> The number for the various types of faults will also need to be 
> adjusted. Looking at 2.6.13-1.1526 kernel used in FC4.
> 
> linux-2.6.13/include/linux/mm.h has:
> 
> #define VM_FAULT_OOM    0x00
> #define VM_FAULT_SIGBUS 0x01
> #define VM_FAULT_MINOR  0x02
> #define VM_FAULT_MAJOR  0x03
> 
> I noticed this because of the large number of major faults without any 
> minor faults recorded. However, using the numbers above I see values 
> that look more reasonable for minor faults, but I don't see any major 
> faults counted when I was playing around with this.
> 

Yes. I noticed that too. Is there a sane of handling these between
two kernel versions ? (like function name changes, #define changes, 
disappearing functions).

I tried doing,

#if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
probe kernel.function("handle_mm_fault") {
#else
probe kernel.function("__handle_mm_fault") {
#endif

But doesn't work.

Thanks,
Badari

Re: pfaults.stp fix (for 2.6.13 and beyond)

[Frank Ch. Eigler]

Badari Pulavarty <pbadari@us.ibm.com> writes:

> Yes. I noticed that too. Is there a sane of handling these between
> two kernel versions ? (like function name changes, #define changes,
> disappearing functions).

There isn't an easy way for end-user scripts.  Scripts installed under
tapset/ can use the kernel-version-sensitive search paths.  I
envisioned hiding such version drift in these tapset variants exactly
so that end-user scripts would not need to be aware.  But perhaps this
is not sufficient.

> I tried doing,
> #if LINUX_VERSION_CODE < KERNEL_VERSION(2,6,13)
> probe kernel.function("handle_mm_fault") {
> #else
> probe kernel.function("__handle_mm_fault") {
> #endif
> But doesn't work.

That is because stp sources are not processed through cpp, and even if
they were, it'd have to be told to locate kernel headers that define
such macros, and yet avoid pulling in all the C code.

Several people have suggested a version-sensitive ifdef construct for
the scripting language, and I'm finally coming around on that.  I'll
open a bugzilla entry to track its implementation.

- FChE