[Bug kprobes/22147] stopped to probe do_arch_ctrl_64

["dsmith at redhat dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22147

David Smith <dsmith at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dsmith at redhat dot com

--- Comment #2 from David Smith <dsmith at redhat dot com> ---
(In reply to nlz from comment #0)

... stuff deleted ...

> some times it did probe but it stopped to do it.
> It is not clear  what is changed.
> I did kernel and systemtap upgrade.
> But return to previous 4.12.9 where I had it working
> but behavour the same as for 4.12.12

OK, let's try to clarify some things here to make sure I understand you.

- With systemtap version X and kernel 4.12.9, the above script worked for you.

- You then upgraded systemtap and the kernel

- With systemtap version Y and kernel 4.12.12, the above script causes a kernel
BUG.

The first thing I'll need to know is what version of systemtap did you start
with, and what version did you upgrade to.

Anytime a systemtap module causes a kernel BUG, that's a systemtap problem that
we'll need to fix.

Of course your function my_get_fs_base() is quite scary. If you comment out the
call to that function, do you still get the kernel BUG? Is that function based
on some code in the kernel or did you write it from scratch yourself?

Here's another oddity in your code. The following probe is quite mixed up:

====
probe kernel.function("do_arch_prctl_64").call 
{
 if ( pid() == target() ) {
    if ( ulonglong_arg(2) ==  0x1002 ) {
      ++cnt_fs_base_set
      printf ("do_arch_prctl_64 ARCH_SET_FS fun %s option %x arg %x\n",
ppfunc(), ulonglong_arg(2), ulonglong_arg(3) )
     printf( " tid %d current fs base %x \n", tid(), my_get_fs_base() )

    }
 }
}
====

You ask for a dwarf-based function probe ("kernel.function"), then you use
dwarfless argument handling (ulonglong_arg() calls instead of just using
dwarf-based argument handling - $option and $arg2 in this case). In theory this
should be OK for x86_64, but note that we never test it. I'd either switch to
dwarfless-based function probling (i.e. "kprobe.function") or dwarf-based
argument handling.

We can start looking at your DMESG output once you let us know what versions of
systemtap you were using.

Another thing, are you using a self-built kernel or a distro kernel? Are you
using self-built versions of systemtap or distro versions?

> Any clue what is wrong with systemstap?
> Is it systemtap problem or problem of linux kernel?
> 
> Why pass 2 run ~25 minutes? Is it expected so long time.

Pass 2 shouldn't take 25 minutes. It does parse the entire tapset library and
then your script, but it shouldn't take 25 minutes. I'm not sure what to think
here. Please answer my above questions and we'll try to help you figure this
out also.

-- 
You are receiving this mail because:
You are the assignee for the bug.