From: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
To: David Smith <dsmith@redhat.com>
Cc: Systemtap List <systemtap@sources.redhat.com>, ltt-dev@shafik.org
Subject: Re: Linux kernel marker questions
Date: Mon, 28 May 2007 18:23:00 -0000 [thread overview]
Message-ID: <20070528182305.GD7882@Krystal> (raw)
In-Reply-To: <46531C6E.3010502@redhat.com>
* 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
next prev parent reply other threads:[~2007-05-28 18:23 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-05-22 16:38 David Smith
2007-05-23 7:10 ` Mathieu Desnoyers
2007-05-23 21:15 ` Mike Mason
2007-05-24 13:21 ` David Smith
2007-05-24 13:59 ` Mike Mason
2007-05-24 14:13 ` David Smith
2007-05-28 18:23 ` Mathieu Desnoyers [this message]
2007-05-29 13:24 ` David Smith
2007-05-29 14:15 ` Target variable that was defined by our own kernel module John Liang
2007-05-29 15:09 ` David Smith
2007-05-29 17:27 ` John Liang
2007-05-29 18:19 ` David Smith
2007-05-29 18:03 ` Stone, Joshua I
2007-05-29 21:00 ` Linux kernel marker questions Frank Eigler
2007-05-30 15:28 ` [Ltt-dev] " Mathieu Desnoyers
2007-05-30 17:01 ` Frank Ch. Eigler
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20070528182305.GD7882@Krystal \
--to=mathieu.desnoyers@polymtl.ca \
--cc=dsmith@redhat.com \
--cc=ltt-dev@shafik.org \
--cc=systemtap@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).