Linux kernel marker questions

Linux kernel marker questions

[David Smith]

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.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Linux kernel marker questions

[Mathieu Desnoyers]

Hi David,

I am currently on vacation, so I'll reply in full on May 28, when I'll
be back. Meanwhile, you can get a head-start by looking at the new
implementation of the markers in LTTng 0.9.6 (http://ltt.polymtl.ca): I
modified it quite a bit, taking in consideration comments from the
kernel community. The API did not change much though (just be cautious
of the new return value of marker_arm_probe, which is the logical
opposite of the old marker_set_probe).

Regards,

Mathieu

* David Smith (dsmith@redhat.com) 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.
> 
> -- 
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Linux kernel marker questions

[Mike Mason]

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

Re: Linux kernel marker questions

[David Smith]

Mike Mason wrote:
> 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?

Yes it should work - depending on which version of Mathieu's patches 
you've got.  I've bet we've got differing versions if you are getting 
the "bad __markers_string section" message.  I've been using the version 
of Mathieu's patches that Andrew Morton has.  I can send you a copy of 
the patches I've been using if you'd like.

One more thing - your marker is called "sem_down", but you look to be 
putting a probe on "sem_up"...

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Linux kernel marker questions

[Mike Mason]

David Smith wrote:
> Mike Mason wrote:
>> 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?
> 
> Yes it should work - depending on which version of Mathieu's patches 
> you've got.  I've bet we've got differing versions if you are getting 
> the "bad __markers_string section" message.  I've been using the version 
> of Mathieu's patches that Andrew Morton has.  I can send you a copy of 
> the patches I've been using if you'd like.

I'm using a version of the Andrew's patches, but perhaps not the latest.  Please send me what you're using.

> 
> One more thing - your marker is called "sem_down", but you look to be 
> putting a probe on "sem_up"...
> 

Oops, cut-and-paste error.  I do have a "sem_up" marker as well.

BTW, what data can be accessed in a SystemTap marker probe handler?  Can it access the data defined by the marker or any local or global variables?

Thanks,
Mike

Re: Linux kernel marker questions

[David Smith]

Mike Mason wrote:
> David Smith wrote:
>> Mike Mason wrote:
>>> Should this work yet?
>>
>> Yes it should work - depending on which version of Mathieu's patches 
>> you've got.  I've bet we've got differing versions if you are getting 
>> the "bad __markers_string section" message.  I've been using the 
>> version of Mathieu's patches that Andrew Morton has.  I can send you a 
>> copy of the patches I've been using if you'd like.
> 
> I'm using a version of the Andrew's patches, but perhaps not the 
> latest.  Please send me what you're using.

I'll send you the patches I've been using.

> BTW, what data can be accessed in a SystemTap marker probe handler?  Can 
> it access the data defined by the marker or any local or global variables?

You'll only be able to access the data defined by the marker using 
"$argN" (where "N" is 1 through the number of arguments).

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Linux kernel marker questions

[Mathieu Desnoyers]

* David Smith (dsmith@redhat.com) 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?
> 

Yes. A marker can be declared more than once, but bears the same
semantics and should have the same parameter types.

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

See answer below. Also, if a marker is defined in an inline function or
an unrolled loop (this last optimization is disabled in the kernel build
though), it will result in multiple occurences of the marker.

> 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?
> 

Correct. It could be fixed by adapting _marker_set_probe, making it take
an optinional struct module* argument. It will have more effects on the
forthcoming markers version though, since I keep a data structure of the
active markers throrough the kernel, so that if a marker is set before a
module is loaded, the marker will be activated at module load time.

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

format string and flags are only there to make sure nobody writes
foolishly a "bad" probe without considering the reentrancy impact and
by expecting the wrong arguments. Note that passing a NULL format string
is valid and means that the probe will parse the string dynamicall,
therefore getting around the verification.

> 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?
> 

Hrm.. well, isn't this information is a __markers section, which points
to a __markers data section ? It seems to me that it could be extracted
from the binary too, just like the __markers_strings. Please keep in
mind that these sections and data structures will change in the
forthcoming markers version.


> 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?
> 

It will change in the new version. I guess we should rediscuss it once I
submit the new patches.

> Thanks for the help.
> 

Thanks for your collaboration, I hope I answered to your questions
appropriately.

Mathieu

> -- 
> David Smith
> dsmith@redhat.com
> Red Hat
> http://www.redhat.com
> 256.217.0141 (direct)
> 256.837.0057 (fax)

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: Linux kernel marker questions

[David Smith]

Mathieu Desnoyers wrote:
> * David Smith (dsmith@redhat.com) wrote:
>> Am I correct that unique marker names are not strictly enforced but 
>> "uniqueness" is more of a convention?
> 
> Yes. A marker can be declared more than once, but bears the same
> semantics and should have the same parameter types.

OK.

>> 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?
>>
> 
> Correct. It could be fixed by adapting _marker_set_probe, making it take
> an optinional struct module* argument.

That might be useful.  I can see situations where you would want to 
enable a marker only in a specific module.


>> 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.
>>
> 
> format string and flags are only there to make sure nobody writes
> foolishly a "bad" probe without considering the reentrancy impact and
> by expecting the wrong arguments. Note that passing a NULL format string
> is valid and means that the probe will parse the string dynamicall,
> therefore getting around the verification.

OK, so I can pass a NULL as the format string.  I'm more worried at this 
point about the flags than the format string, since I currently don't 
have a way to retrieve the flags.

>> 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?
>>
> 
> Hrm.. well, isn't this information is a __markers section, which points
> to a __markers data section ? It seems to me that it could be extracted
> from the binary too, just like the __markers_strings. Please keep in
> mind that these sections and data structures will change in the
> forthcoming markers version.

In the kernel that I built using your patches, I end up with a 
'__markers' section (which basically contains the enabled state of each 
marker), and the '__markers_strings' section, which contains the marker 
names and format strings.  The '__markers_data' section doesn't exist as 
a separate section, it is just part of the data section.

Of course another problem I've got is that the definitions of the data 
structures aren't available from user-space.

>> 3) From systemtap's point of view, _marker_set_probe() doesn't return 
>> enough error information.
>>
>> Would there be any way of getting more detailed error information?
>>
> 
> It will change in the new version. I guess we should rediscuss it once I
> submit the new patches.

Great.  Do you have any ideas on when you plan on submitting the new 
patches?

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Target variable that was defined by our own kernel module

[John Liang]

HI There,

For the following systemtap script, I run into a compiler error:

probe module("mymodule").("foobar"){
     if($myparm)
         dosomething
}

It looks if $myparm is a data structure defined in Linux Kernel,
It would compile and run without problem; but if it is a defined
by my own module, then it gave me a "unresolved symbol error for
$myparm". 

Any suggestions to solve this?

Thanks,
--
John Liang

Re: Target variable that was defined by our own kernel module

[David Smith]

John Liang wrote:
> HI There,
> 
> For the following systemtap script, I run into a compiler error:
> 
> probe module("mymodule").("foobar"){
>      if($myparm)
>          dosomething
> }

That first line should be:

    probe module("mymodule").function("foobar"){

> It looks if $myparm is a data structure defined in Linux Kernel,
> It would compile and run without problem; but if it is a defined
> by my own module, then it gave me a "unresolved symbol error for
> $myparm". 
> 
> Any suggestions to solve this?

Make sure the debug information is installed for your kernel module.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

RE: Target variable that was defined by our own kernel module

[John Liang]

David,

Do you mean I need to create a mymodule-debuginfo rpm in the 
same way as for kernel-debuginfo of Linux?

Thanks,
--
John Liang

-----Original Message-----
From: systemtap-owner@sourceware.org [mailto:systemtap-owner@sourceware.org]
On Behalf Of David Smith
Sent: Tuesday, May 29, 2007 11:09 AM
To: John Liang
Cc: 'Systemtap List'
Subject: Re: Target variable that was defined by our own kernel module

John Liang wrote:
> HI There,
> 
> For the following systemtap script, I run into a compiler error:
> 
> probe module("mymodule").("foobar"){
>      if($myparm)
>          dosomething
> }

That first line should be:

    probe module("mymodule").function("foobar"){

> It looks if $myparm is a data structure defined in Linux Kernel,
> It would compile and run without problem; but if it is a defined
> by my own module, then it gave me a "unresolved symbol error for
> $myparm". 
> 
> Any suggestions to solve this?

Make sure the debug information is installed for your kernel module.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Target variable that was defined by our own kernel module

[David Smith]

John Liang wrote:
> David,
> 
> Do you mean I need to create a mymodule-debuginfo rpm in the 
> same way as for kernel-debuginfo of Linux?

Yes or no - depending on how you compile your module.

If you are building via rpmbuild, it should automatically create a 
debuginfo rpm for you which you would then install.

If you are building by hand or via a Makefile, you'll need to ensure the 
module isn't stripped (I believe).

Also, a more exact error message could help us out here.

-- 
David Smith
dsmith@redhat.com
Red Hat
http://www.redhat.com
256.217.0141 (direct)
256.837.0057 (fax)

Re: Target variable that was defined by our own kernel module

[Stone, Joshua I]

David Smith wrote:
> John Liang wrote:
> [...]
>> It looks if $myparm is a data structure defined in Linux Kernel,
>> It would compile and run without problem; but if it is a defined
>> by my own module, then it gave me a "unresolved symbol error for
>> $myparm".
>> Any suggestions to solve this?
> 
> Make sure the debug information is installed for your kernel module.

If it were a problem of locating the debuginfo, I expect that it 
wouldn't even resolve the function, right?

It still may be a case of inadequate debugging information though. 
Perhaps that variable got optimized away, or it may be one of our 
beloved problems with gcc.

Josh

Re: Linux kernel marker questions

[Frank Eigler]

Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:

> [...]  Yes. A marker can be declared more than once, but bears the
> same semantics and should have the same parameter types.

Will the registration API do the right thing with enforcing this?


> [...]  Correct. It could be fixed by adapting _marker_set_probe,
> making it take an optinional struct module* argument. [...]

Unfortunately, it is hard to get a struct module* by a module.  When
last year, we tried to submit a plain module_get_byname() api call, it
got blocked.  Should we try again (with the same patch, natch)?

> forthcoming markers version though, since I keep a data structure of the
> active markers throrough the kernel, so that if a marker is set before a
> module is loaded, the marker will be activated at module load time.

OK, but we will probably still need a separate namespace.

> > 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.
> 
> format string and flags are only there to make sure nobody writes
> foolishly a "bad" probe [...]

For a client such as systemtap, marker probes will be atomic.

> [...] Please keep in mind that these sections and data structures
> will change in the forthcoming markers version. [...]

I hope it settles down soon.  If it doesn't, it will become necessary
to add versioning tags to the marker data so we can guide our decoder.


- FChE

Re: [Ltt-dev] Linux kernel marker questions

[Mathieu Desnoyers]

* Frank Eigler (fche@redhat.com) wrote:
> Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca> writes:
> 
> > [...]  Yes. A marker can be declared more than once, but bears the
> > same semantics and should have the same parameter types.
> 
> Will the registration API do the right thing with enforcing this?
> 
If the format passed to marker_arm_probe is not NULL, each marker will
be checked to match the same format. If not, connexion fails.

> 
> > [...]  Correct. It could be fixed by adapting _marker_set_probe,
> > making it take an optinional struct module* argument. [...]
> 
> Unfortunately, it is hard to get a struct module* by a module.  When
> last year, we tried to submit a plain module_get_byname() api call, it
> got blocked.  Should we try again (with the same patch, natch)?
> 

You could pass a module name to the marker_arm_probe then, instead of a
struct module*. Since marker_arm_probe sits in module.c, it makes things
easy. :)

> > forthcoming markers version though, since I keep a data structure of the
> > active markers throrough the kernel, so that if a marker is set before a
> > module is loaded, the marker will be activated at module load time.
> 
> OK, but we will probably still need a separate namespace.
> 

Hrm, what if you use a semantic like "module_name__subsys_event" in the
marker names ? You could then control marker activation per module if
you like without adding any complexity to the marker infrastructure.

> > > 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.
> > 
> > format string and flags are only there to make sure nobody writes
> > foolishly a "bad" probe [...]
> 
> For a client such as systemtap, marker probes will be atomic.
> 

ok, so if you do not call things like local_irq_enable, nor fall into
debug traps in the handler, you can use the CF_DEFAULT flag for the
marker_arm_probe when you arm your probe : it will imply that your probe
handler won't call into lockdep nor call printk. (meaning that you have
to do everything atomically and, if you _really_ need to do such things
like disabling interrupts, you must use the raw versions which does not
call lockdep).

> > [...] Please keep in mind that these sections and data structures
> > will change in the forthcoming markers version. [...]
> 
> I hope it settles down soon.  If it doesn't, it will become necessary
> to add versioning tags to the marker data so we can guide our decoder.
> 

My feeling it that it should probably go into mainline for 2.6.23, but
things should settle down sooner.

> 
> - FChE
> _______________________________________________
> Ltt-dev mailing list
> Ltt-dev@listserv.shafik.org
> http://listserv.shafik.org/mailman/listinfo/ltt-dev
> 

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68

Re: [Ltt-dev] Linux kernel marker questions

[Frank Ch. Eigler]

Hi, Mathieu -

> You could pass a module name to the marker_arm_probe then, instead of a
> struct module*. Since marker_arm_probe sits in module.c, it makes things
> easy. :)

Indeed.

> > > forthcoming markers version though, since I keep a data structure of the
> > > active markers throrough the kernel, so that if a marker is set before a
> > > module is loaded, the marker will be activated at module load time.
> > 
> > OK, but we will probably still need a separate namespace.
> 
> Hrm, what if you use a semantic like "module_name__subsys_event" in the
> marker names ? You could then control marker activation per module if
> you like without adding any complexity to the marker infrastructure.

But the namespace reflects the actual complexity of the system.  If
you defer marker insertion for modules being loaded on-the-fly, then
the code already knows modules are special, and most of the complexity
is already there.

> > For a client such as systemtap, marker probes will be atomic.
> 
> ok, so if you do not call things like local_irq_enable, nor fall into
> debug traps in the handler, you can use the CF_DEFAULT flag [...]

OK.

> (meaning that you have to do everything atomically and, if you
> _really_ need to do such things like disabling interrupts, you must
> use the raw versions which does not call lockdep).

I don't entirely understand the issue with lockdep.  Is the problem
only that it reports errors via printk?  Could you send a pointer to
more detailed information on new atomicity constraints due to lockdep?


- FChE