Re: Linux kernel marker questions

[Mike Mason <mmlnx at us dot ibm dot com>]

David,

Is there enough marker support in CVS now that we can write scripts against it?  I tried using the latest CVS against a kernel with a few markers, but I'm seeing errors.

Here's the script: 

global sem_up_cnt
probe kernel.mark("sem_up") { sem_up_cnt++ }
probe end { printf("sem_up_cnt = %d\n", sem_up_cnt)}

Here's the marker I'm trying to access in __up() in semaphore-sleepers.c:

MARK(sem_down, "%ul", (unsigned long) sem);

Here are the errors I'm seeing:

semantic error: bad __markers_string section?
semantic error: no match for probe point while resolving probe point kernel.mark("sem_up")

Should this work yet?

Thanks,
Mike

David Smith wrote:
> Mathieu,
>
> I've just finished checking in initial support for your new kernel 
> markers into systemtap.  I've got some rough edges to work on, but in 
> general it works.
>
> As I implemented the marker support, I come up with several questions 
> I'd like some help/clarification with.
>
> 1)  According to Documentation/marker.txt, the marker name 
> (subsystem_event) is "is an identifier unique to your event".
>
> Am I correct that unique marker names are not strictly enforced but 
> "uniqueness" is more of a convention?
>
> _marker_set_probe() seems to support the view that marker names aren't 
> unique since it doesn't stop looking for more marker matches once it 
> finds a match.
>
> One problem this creates for systemtap is that systemtap's probe syntax 
> looks like 'kernel.mark("marker_name")' and 
> 'module("module_name").mark('marker_name').  I believe with the current 
> code if a marker exists with the same name, format string, and flags in 
> the kernel and a loadable module there isn't any way to only enable the 
> marker in one place or the other - you can only enable both markers 
> (assuming the module is loaded).  Am I correct?
>
> 2) _marker_set_probe() expects the marker name, format string, and flags 
> that were specified when the marker was inserted.  If marker names were 
> truly unique, I would really only need the marker name to enable a marker.
>
> Since systemtap can compile modules for a kernel that isn't running, I 
> can't really use marker_list_probe() for getting a list of markers 
> present (even if the output of marker_list_probe() was more than just 
> printks).  So, currently to get a list of markers for a particular 
> kernel, the code reads and parses the kernel/module '__markers_strings' 
> elf section, which gets systemtap the marker names and format strings. 
> (Getting the marker flags out of a kernel/module elf file is possible, 
> but won't be easy.)
>
> Currently systemtap can only enable markers that used the MF_DEFAULT set 
> of flags.
>
> Have you got any ideas on how systemtap (or any other program) can get a 
> list of all the data _marker_set_probe needs?
>
> 3) From systemtap's point of view, _marker_set_probe() doesn't return 
> enough error information.  Currently it just returns the number of 
> probes enabled.  If _marker_set_probe returns a 0 (meaning no markers 
> were enabled), I don't know which of the following that means:
>
> - the marker name wasn't found
> - the marker name was found, but format string didn't match the compiled 
> format string
> - the marker name was found and the format strings matched, but the 
> marker flags didn't match the compiled marker flags
> - the marker is already enabled (since markers can only have one 
> function attached to them at a time)
>
> Would there be any way of getting more detailed error information?
>
> Thanks for the help.