n Merey, Alice Zhang, Craig Ringer, Frank Ch. Eigler, Martin Cermak,
Sagar Patel, Sergei Trofimovich*, Serhei Makarov, Stan Cox, Sultan Alsawaf*,
Thorsten Glaser*, William Cohen, Yichun Zhang (agentzh)
Special thanks to new contributors, marked with '*' above.
Special thanks to Aaron Merey for d
Hi -
> > > I need to support this in pahole...
> >
> > pahole/dwarves use elfutils, so it already has automatic support.
> > https://sourceware.org/elfutils/Debuginfod.html
>
> I'm still not sure that which interface of elfutils I should use
> for this "automatic" debuginfod support. Are there
Hi -
> > Nice, even uses the source code fetching part of the webapi!
>
> So, can I take that as an Acked-by or Reviewed-by?
Sure.
> I need to support this in pahole...
pahole/dwarves use elfutils, so it already has automatic support.
https://sourceware.org/elfutils/Debuginfod.html
- FChE
Hi -
Nice, even uses the source code fetching part of the webapi!
- FChE
Masami Hiramatsu writes:
> Sorry, for noticing this point, I Cc'd to systemtap. Is systemtap taking
> care of spinlock too?
On PRREMPT_RT configurations, systemtap uses the raw_spinlock_t
types/functions, to keep its probe handlers as atomic as we can make them.
- FChE
Hi -
> > We have relocated based on sections, not some subset of function
> > symbols accessible that way, partly because DWARF line- and DIE- based
> > probes can map to addresses some way away from function symbols, into
> > function interiors, or cloned/moved bits of optimized code. It would
Hi -
On Mon, Aug 03, 2020 at 01:11:27PM -0700, Kees Cook wrote:
> [...]
> > Systemtap needs to know base addresses of loaded text & data sections,
> > in order to perform relocation of probe point PCs and context data
> > addresses. It uses /sys/module/, kind of under protest, because
> >
Hi -
> > While this does seem to be the right solution for the extant problem, I
> > do want to take a moment and ask if the function sections need to be
> > exposed at all? What tools use this information, and do they just want
> > to see the bounds of the code region? (i.e. the start/end of all
egister.
(PR13429)
- The presence of a line such as
*CFLAGS += $(call cc-option, -fno-var-tracking-assignments)
in the linux kernel Makefile unnecessarily reduces debuginfo quality,
consider removing that line if you build kernels.
= Contributors for this release
Aaron Merey, Alice Zh
Hi -
> > While auditing all module notifiers I noticed a whole bunch of fail
> > wrt the return value. Notifiers have a 'special' return semantics.
>From peterz's comments, the patches, it's not obvious to me how one is
to choose between 0 (NOTIFY_DONE) and 1 (NOTIFY_OK) in the case of a
routine
ents)
= Coming soon
- prometheus-exporter is here, more tasty systemtap & http chocolate en route
= Contributors for this release
Aaron Merey, David Smith, Frank Ch. Eigler, Jafeer Uddin, Martin Cermak,
Masanari Iida, *Paulo Andrade, Serhei Makarov, Stan Cox, Victor Kamensky,
William Coh
ents)
= Coming soon
- prometheus-exporter is here, more tasty systemtap & http chocolate en route
= Contributors for this release
Aaron Merey, David Smith, Frank Ch. Eigler, Jafeer Uddin, Martin Cermak,
Masanari Iida, *Paulo Andrade, Serhei Makarov, Stan Cox, Victor Kamensky,
William Coh
Rik van Riel writes:
> [...] The goal of the code of conduct is to make the community
> welcoming, and to help people with being a part of the Linux
> community. [...]
That may well be the goal. But the proper way to evaluate policy is not
the laudability of its goals but its forseeable
Rik van Riel writes:
> [...] The goal of the code of conduct is to make the community
> welcoming, and to help people with being a part of the Linux
> community. [...]
That may well be the goal. But the proper way to evaluate policy is not
the laudability of its goals but its forseeable
utter and chocolate
= Contributors for this release
Aaron Merey, *Aryeh Weinreb, *Bernhard Wiedemann, David Smith, Frank
Ch. Eigler, *Gustavo Moreira, *Igor Gnatenko, *Iryna Shcherbina, *Jafeer
Uddin, Jeff Moyer, *Lukas Herbolt, Mark Wielaard, Martin Cermak, *Petr
Viktorin, Serhei Makarov, Stan
utter and chocolate
= Contributors for this release
Aaron Merey, *Aryeh Weinreb, *Bernhard Wiedemann, David Smith, Frank
Ch. Eigler, *Gustavo Moreira, *Igor Gnatenko, *Iryna Shcherbina, *Jafeer
Uddin, Jeff Moyer, *Lukas Herbolt, Mark Wielaard, Martin Cermak, *Petr
Viktorin, Serhei Makarov, Stan
mhiramat wrote:
> Here is a correction of patches to introduce kretprobe_instance
> dynamic allocation for avoiding kretprobe silently miss-hits.
> [...]
Thanks, this looks automatically useful also to systemtap users.
- FChE
mhiramat wrote:
> Here is a correction of patches to introduce kretprobe_instance
> dynamic allocation for avoiding kretprobe silently miss-hits.
> [...]
Thanks, this looks automatically useful also to systemtap users.
- FChE
Hi, Tom -
tom.zanussi wrote:
> [...]
>> Hmm, this looks a bit hard to understand, I guess that onmatch() means
>> "if there is an event which has ts0 variable and the event's key matches
>> this key, take some action".
>
> Yes, that's pretty much it. It's essentially shorthand for this kind of
Hi, Tom -
tom.zanussi wrote:
> [...]
>> Hmm, this looks a bit hard to understand, I guess that onmatch() means
>> "if there is an event which has ts0 variable and the event's key matches
>> this key, take some action".
>
> Yes, that's pretty much it. It's essentially shorthand for this kind of
Hi, Thomas -
> Well, if you are not in thread context then the check is pointless:
> __range_not_ok(addr, size, user_addr_max())
> and:
> #define user_addr_max() (current->thread.addr_limit.seg)
>
> So what guarantees when you are not in context of current, i.e. in thread
> context, that
Hi, Thomas -
> Well, if you are not in thread context then the check is pointless:
> __range_not_ok(addr, size, user_addr_max())
> and:
> #define user_addr_max() (current->thread.addr_limit.seg)
>
> So what guarantees when you are not in context of current, i.e. in thread
> context, that
Hi, Thomas -
On Thu, Jan 19, 2017 at 07:12:48PM +0100, Thomas Gleixner wrote:
> [...]
> It does matter very much, because the fact that the warning triggers tells
> me that it's placed in code which is NOT executed in task context.
> [...]
> We are not papering over problems.
Understood. We
Hi, Thomas -
On Thu, Jan 19, 2017 at 07:12:48PM +0100, Thomas Gleixner wrote:
> [...]
> It does matter very much, because the fact that the warning triggers tells
> me that it's placed in code which is NOT executed in task context.
> [...]
> We are not papering over problems.
Understood. We
brendan.d.gregg wrote:
> [...]
> Great! Is there a hello world example in there somewhere? I found this:
> [...]
Yup. Here is a smoke test. (A great many other things are not yet
working.)
% sudo ./stap -v --runtime=bpf -e 'global foo
probe kprobe.function("vfs_read"),
brendan.d.gregg wrote:
> [...]
> Great! Is there a hello world example in there somewhere? I found this:
> [...]
Yup. Here is a smoke test. (A great many other things are not yet
working.)
% sudo ./stap -v --runtime=bpf -e 'global foo
probe kprobe.function("vfs_read"),
ils about the state of the feature.
- An upstream kernel commit #2062afb4f804a put "-fno-var-tracking-assignments"
into KCFLAGS, reducing debuginfo quality which can cause debuginfo failures.
A proposed workaround to this issue exists in:
https://lkml.org/lkml/2014/11/21/505 . Fedora ke
ils about the state of the feature.
- An upstream kernel commit #2062afb4f804a put "-fno-var-tracking-assignments"
into KCFLAGS, reducing debuginfo quality which can cause debuginfo failures.
A proposed workaround to this issue exists in:
https://lkml.org/lkml/2014/11/21/505 . Fedora ke
details about the state of the feature.
= Contributors for this release
Abegail Jakop, David Smith, Felix Lu, Frank Ch. Eigler,
Ivan Diorditsa*, Jose Castillo*, Josh Stone, Lukas Berk,
Mark Wielaard, Martin Cermak, Mikhail Kulemin*, Nicolas Brito*
Snehal Phule*
Special thanks to new contr
details about the state of the feature.
= Contributors for this release
Abegail Jakop, David Smith, Felix Lu, Frank Ch. Eigler,
Ivan Diorditsa*, Jose Castillo*, Josh Stone, Lukas Berk,
Mark Wielaard, Martin Cermak, Mikhail Kulemin*, Nicolas Brito*
Snehal Phule*
Special thanks to new contr
Hi, Rusty -
I wrote:
> [...]
> > Notifiers suck for stuff like this :( Module state has many steps,
> > so my preference has been to open-code explicit hooks. [...]
>
> You mean something like the trace_module_load()? (We will probably
> experiment with hooking into that tracepoint instead
Hi, Rusty -
Thanks for your response!
> [...]
> > That patch also moved the MODULE_STATE_COMING notifier call to
> > complete_formation(), which is relatively early to its former
> > do_init_module() call site. It now precedes the parse_args(),
> > mod_sysfs_setup(), and trace_module_load()
Hi, Rusty -
I wrote:
> [...]
> > Notifiers suck for stuff like this :( Module state has many steps,
> > so my preference has been to open-code explicit hooks. [...]
>
> You mean something like the trace_module_load()? (We will probably
> experiment with hooking into that tracepoint instead
Hi, Rusty -
Thanks for your response!
> [...]
> > That patch also moved the MODULE_STATE_COMING notifier call to
> > complete_formation(), which is relatively early to its former
> > do_init_module() call site. It now precedes the parse_args(),
> > mod_sysfs_setup(), and trace_module_load()
Hi, Rusty -
We just [1] came across your patch [2] from last year (merged into
3.17), wherein the RO/NX mapping settings for module sections were
moved to an earlier point in the module-loading sequence.
That patch also moved the MODULE_STATE_COMING notifier call to
complete_formation(), which
Hi, Rusty -
We just [1] came across your patch [2] from last year (merged into
3.17), wherein the RO/NX mapping settings for module sections were
moved to an earlier point in the module-loading sequence.
That patch also moved the MODULE_STATE_COMING notifier call to
complete_formation(), which
Hi -
On Fri, May 29, 2015 at 03:27:16PM -0500, Josh Poimboeuf wrote:
> [...]
> > > Also, with the feature missing completely, maybe someone finds a method to
> > > introduce it in a maintainable fashion, while with the feature included
> > > upstream
> > > there's very little pressure to do
Hi -
On Fri, May 29, 2015 at 03:27:16PM -0500, Josh Poimboeuf wrote:
[...]
Also, with the feature missing completely, maybe someone finds a method to
introduce it in a maintainable fashion, while with the feature included
upstream
there's very little pressure to do that. As a bonus
Hi, Josh -
On Fri, Apr 24, 2015 at 08:40:02AM -0400, Josh Boyer wrote:
> [...]
> Frank, did you rebase this against some newer tree or something?
Yes; the lib/Kconfig.debug part didn't apply to current git.
> Curious why you sent it again.
At least as a patch-ping; the poor-debuginfo problems
Hi, Josh -
On Fri, Apr 24, 2015 at 08:40:02AM -0400, Josh Boyer wrote:
[...]
Frank, did you rebase this against some newer tree or something?
Yes; the lib/Kconfig.debug part didn't apply to current git.
Curious why you sent it again.
At least as a patch-ping; the poor-debuginfo problems are
Signed-off-by: Frank Ch. Eigler
---
Makefile | 8 ++--
lib/Kconfig.debug | 21 -
2 files changed, 26 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 6cc5b2434224..c8e1fcfdb41a 100644
--- a/Makefile
+++ b/Makefile
@@ -704,8 +704,6 @@ KBU
-foundation.org
Cc: Andrew Morton a...@linux-foundation.org
Cc: Markus Trippelsdorf mar...@trippelsdorf.de
Cc: Michel Dänzer mic...@daenzer.net
Signed-off-by: Josh Stone jist...@redhat.com
Signed-off-by: Frank Ch. Eigler f...@redhat.com
---
Makefile | 8 ++--
lib/Kconfig.debug | 21
Hi -
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
> > Actually, "perf probe" does (via HAVE_DWARF_SUPPORT), to place probes
> > and to extract variables at those probes, much as systemtap does.
> > Without var-tracking, probes placed at most interior points of
> > functions
Hi -
> >>. I don't disagree it should be
> >> disabled by default, but making it unconditional is going to force the
> >> distributions that care about perf, systemtap, and debuggers to
> >> manually revert this.
> >
> > Bah. I bet I use 'perf' more than most, and it doesn't care about
> > debug
Hi -
. I don't disagree it should be
disabled by default, but making it unconditional is going to force the
distributions that care about perf, systemtap, and debuggers to
manually revert this.
Bah. I bet I use 'perf' more than most, and it doesn't care about
debug info.
Actually,
Hi -
On Tue, Aug 05, 2014 at 03:36:39PM -0700, Linus Torvalds wrote:
Actually, perf probe does (via HAVE_DWARF_SUPPORT), to place probes
and to extract variables at those probes, much as systemtap does.
Without var-tracking, probes placed at most interior points of
functions will make
Hi, Alexei -
> My understanding of systemtap is that the whole .stp script is converted
> to C, compiled as .ko and loaded, so all map walking and prints are
> happening in the kernel. Similarly for ktap which has special functions
> in kernel to print histograms.
That is correct.
> I thought
ast wrote earlier:
> [...]
> dtrace/systemtap/ktap approach is to use one script file that should provide
> all desired functionality. That architectural decision overcomplicated their
> implementations.
>
> eBPF follows split model: everything that needs to process millions of events
> per
ast wrote earlier:
[...]
dtrace/systemtap/ktap approach is to use one script file that should provide
all desired functionality. That architectural decision overcomplicated their
implementations.
eBPF follows split model: everything that needs to process millions of events
per second
Hi, Alexei -
My understanding of systemtap is that the whole .stp script is converted
to C, compiled as .ko and loaded, so all map walking and prints are
happening in the kernel. Similarly for ktap which has special functions
in kernel to print histograms.
That is correct.
I thought dtrace
Hi -
On Mon, Jul 28, 2014 at 09:10:04AM -0400, Theodore Ts'o wrote:
> [...]
> I thought Markus told us that -fno-var-tracking-assignments makes
> absolutely no difference for non-debug kernels?
It does affect CONFIG_DEBUG_INFO kernels, and that config option is
set for all Red Hat kernels
torvalds wrote:
> [...]
> Actually, I prefer my patch that did it with cc-option checking, and
> does it unconditionally.
>
> Because if we do it even for non-debug builds - where it ostensibly
> shouldn't matter - we then have that GCC_COMPARE_DEBUG thing working
> regardless of configuration.
torvalds wrote:
[...]
Actually, I prefer my patch that did it with cc-option checking, and
does it unconditionally.
Because if we do it even for non-debug builds - where it ostensibly
shouldn't matter - we then have that GCC_COMPARE_DEBUG thing working
regardless of configuration.
Please
Hi -
On Mon, Jul 28, 2014 at 09:10:04AM -0400, Theodore Ts'o wrote:
[...]
I thought Markus told us that -fno-var-tracking-assignments makes
absolutely no difference for non-debug kernels?
It does affect CONFIG_DEBUG_INFO kernels, and that config option is
set for all Red Hat kernels (-debug
Hi -
On Thu, Mar 13, 2014 at 12:10:48PM -0400, Mathieu Desnoyers wrote:
> [...] Moreover, tracers are responsible for unregistering the probe
> before the module containing its associated tracepoint is unloaded.
Could you spell out please how a tracer is supposed to know early
enough that the
Hi -
On Thu, Mar 13, 2014 at 12:10:48PM -0400, Mathieu Desnoyers wrote:
[...] Moreover, tracers are responsible for unregistering the probe
before the module containing its associated tracepoint is unloaded.
Could you spell out please how a tracer is supposed to know early
enough that the
Hi, Steven -
> > So it is a deferred-activation kind of call, with no way of knowing
> > when or if the tracepoints will start coming in. Why is that
> > supported at all, considering that clients could monitor modules
> > coming & going via the module_notifier chain, and update registration
> >
Hi, Steven -
So it is a deferred-activation kind of call, with no way of knowing
when or if the tracepoints will start coming in. Why is that
supported at all, considering that clients could monitor modules
coming going via the module_notifier chain, and update registration
at that
Hi -
>> From: Steven Rostedt
>>
>> Tracepoints were made to allow enabling a tracepoint in a module before that
>> module was loaded. When a tracepoint is enabled and it does not exist, the
>> name is stored and will be enabled when the tracepoint is created.
>>
>> The problem with this
Hi -
From: Steven Rostedt rost...@goodmis.org
Tracepoints were made to allow enabling a tracepoint in a module before that
module was loaded. When a tracepoint is enabled and it does not exist, the
name is stored and will be enabled when the tracepoint is created.
The problem with this
rostedt wrote:
> [...]
> Oh! You are saying that if the kernel only *supports* signed modules,
> and you load a module that is not signed, it will taint the kernel?
Yes: this is the default for several distros.
- FChE
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
rostedt wrote:
[...]
Oh! You are saying that if the kernel only *supports* signed modules,
and you load a module that is not signed, it will taint the kernel?
Yes: this is the default for several distros.
- FChE
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
Hi -
> > So the similar thing happens when we enables events as below;
> >
> > # for i in /sys/kernel/debug/tracing/events/kprobes/* ; do date; echo 1 >
> > $i; done
> > Wed Jan 29 10:44:50 UTC 2014
> > ...
> >
> > I tried it and canceled after 4 min passed. It enabled about 17k
> >
Hi -
So the similar thing happens when we enables events as below;
# for i in /sys/kernel/debug/tracing/events/kprobes/* ; do date; echo 1
$i; done
Wed Jan 29 10:44:50 UTC 2014
...
I tried it and canceled after 4 min passed. It enabled about 17k
events and slowed down
Hi -
mingo wrote:
> [...]
> For example a hash table (hashed by probe address) could be used in
> addition to the list, to speed up basic operations.
In the past, when this sort of behavior popped up, it was due to
machine-wide halt/sync operations being done too eagerly. At one
point, the
Hi -
mingo wrote:
[...]
For example a hash table (hashed by probe address) could be used in
addition to the list, to speed up basic operations.
In the past, when this sort of behavior popped up, it was due to
machine-wide halt/sync operations being done too eagerly. At one
point, the
Hi, Masami -
masami.hiramatsu.pt wrote:
> Here is the version 6 of NOKPROBE_SYMBOL series. :)
> [...]
Some preliminary results from building these on top of tip/master on
x86-64.
# stap -te "probe kprobe.function("*") {}"
starts up OK, without crashes, which looks like great progress.
Hi, Masami -
masami.hiramatsu.pt wrote:
Here is the version 6 of NOKPROBE_SYMBOL series. :)
[...]
Some preliminary results from building these on top of tip/master on
x86-64.
# stap -te probe kprobe.function(*) {}
starts up OK, without crashes, which looks like great progress. But a
masami.hiramatsu.pt wrote:
> [...]
> Anyway, as far as I can see, there looks be two different models of
> tracing in our mind.
>
> A) Fixed event based tracing: In this model, there are several fixed
> "events" which well defined with fixed arguments. tracer handles these
> events and only use
masami.hiramatsu.pt wrote:
[...]
Anyway, as far as I can see, there looks be two different models of
tracing in our mind.
A) Fixed event based tracing: In this model, there are several fixed
events which well defined with fixed arguments. tracer handles these
events and only use limited
Hi -
On Sat, Dec 07, 2013 at 08:19:13AM +0900, Masami Hiramatsu wrote:
> [...]
> > Would you plan to limit kprobes (or just the perf-probe frontend) to
> > only function-entries also?
> Exactly, yes :). Currently I have a patch for kprobe-tracer
> implementation (not only for perf-probe, but
hpa wrote:
>> I can see there may be some setups which don't have a compiler
>> (e.g. I know some people don't use systemtap because of that)
>> But this needs a custom gcc install too as far as I understand.
>
> Yes... but no compiler and secure boot tend to go together, or at
> least will in
Hi, Masami -
masami.hiramatsu.pt wrote:
> [...]
> >> [...] Then, I'd like to propose this new whitelist feature in
> >> kprobe-tracer (not raw kprobe itself). And a sysctl knob for
> >> disabling the whitelist. That knob will be
> >> /proc/sys/debug/kprobe-event-whitelist and disabling it will
Hi, Masami -
masami.hiramatsu.pt wrote:
[...]
[...] Then, I'd like to propose this new whitelist feature in
kprobe-tracer (not raw kprobe itself). And a sysctl knob for
disabling the whitelist. That knob will be
/proc/sys/debug/kprobe-event-whitelist and disabling it will mark
hpa wrote:
I can see there may be some setups which don't have a compiler
(e.g. I know some people don't use systemtap because of that)
But this needs a custom gcc install too as far as I understand.
Yes... but no compiler and secure boot tend to go together, or at
least will in the
Hi -
On Sat, Dec 07, 2013 at 08:19:13AM +0900, Masami Hiramatsu wrote:
[...]
Would you plan to limit kprobes (or just the perf-probe frontend) to
only function-entries also?
Exactly, yes :). Currently I have a patch for kprobe-tracer
implementation (not only for perf-probe, but doesn't
Andi Kleen writes:
> [...] While it sounds interesting, I would strongly advise to make
> this capability only available to root. Traditionally lots of
> complex byte code languages which were designed to be "safe" and
> verifiable weren't really. e.g. i managed to crash things with
> "safe"
ast wrote:
>>[...]
> Did simple ktap test with 1M alloc_skb/kfree_skb toy test from earlier email:
> trace skb:kfree_skb {
> if (arg2 == 0x100) {
> printf("%x %x\n", arg1, arg2)
> }
> }
> [...]
For reference, you might try putting systemtap into the performance
Hi, Masami -
masami.hiramatsu.pt wrote:
> [...]
> For the safeness of kprobes, I have an idea; introduce a whitelist
> for dynamic events. AFAICS, the biggest unstable issue of kprobes
> comes from putting *many* probes on the functions called from tracers.
Why do you think so? We have had
Hi, Masami -
masami.hiramatsu.pt wrote:
[...]
For the safeness of kprobes, I have an idea; introduce a whitelist
for dynamic events. AFAICS, the biggest unstable issue of kprobes
comes from putting *many* probes on the functions called from tracers.
Why do you think so? We have had
ast wrote:
[...]
Did simple ktap test with 1M alloc_skb/kfree_skb toy test from earlier email:
trace skb:kfree_skb {
if (arg2 == 0x100) {
printf(%x %x\n, arg1, arg2)
}
}
[...]
For reference, you might try putting systemtap into the performance
comparison
Andi Kleen a...@firstfloor.org writes:
[...] While it sounds interesting, I would strongly advise to make
this capability only available to root. Traditionally lots of
complex byte code languages which were designed to be safe and
verifiable weren't really. e.g. i managed to crash things
Alexei Starovoitov writes:
> [...]
>> Having EBPF code manipulating pointers - or kernel memory - directly
>> seems like a nonstarter. However, per your subsequent paragraph it
>> sounds like pointers are a special type at which point it shouldn't
>> matter at the EBPF level how many bytes it
Alexei Starovoitov a...@plumgrid.com writes:
[...]
Having EBPF code manipulating pointers - or kernel memory - directly
seems like a nonstarter. However, per your subsequent paragraph it
sounds like pointers are a special type at which point it shouldn't
matter at the EBPF level how many
Hi -
> > Does this new blacklist cover enough that the kernel now survives a
> > broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms?
>
> That's generally the purpose of the annotations - if it doesn't then
> that's a bug.
AFAIK, no kernel since kprobes was introduced has ever
masami.hiramatsu.pt wrote:
> [...] This series also includes a change which prohibits probing on
> the address in .entry.text because the code is used for very
> low-level sensitive interrupt/syscall entries. Probing such code may
> cause unexpected result (actually most of that area is already
masami.hiramatsu.pt wrote:
[...] This series also includes a change which prohibits probing on
the address in .entry.text because the code is used for very
low-level sensitive interrupt/syscall entries. Probing such code may
cause unexpected result (actually most of that area is already in
Hi -
Does this new blacklist cover enough that the kernel now survives a
broadly wildcarded perf-probe, e.g. over e.g. all of its kallsyms?
That's generally the purpose of the annotations - if it doesn't then
that's a bug.
AFAIK, no kernel since kprobes was introduced has ever stood up
Pekka Enberg writes:
> Is there a technical reason why 'perf list' could not show all the
> available SDT markers on a system and that the 'mark to event'
> mapping cannot happen automatically? [...]
A quick experiment with:
find `echo $PATH | tr : ' '` -type f -perm -555 |
xargs
Pekka Enberg penb...@kernel.org writes:
Is there a technical reason why 'perf list' could not show all the
available SDT markers on a system and that the 'mark to event'
mapping cannot happen automatically? [...]
A quick experiment with:
find `echo $PATH | tr : ' '` -type f -perm -555 |
Hemant Kumar writes:
> [...]
> A simple example to show this follows.
> - Create a file with .d extension and mention the probe names in it with
> provider name and marker name.
> [...]
> - Now create the probes.h and probes.o file :
> $ dtrace -C -h -s probes.d -o probes.h
> $ dtrace -C -G -s
Hemant Kumar hks...@linux.vnet.ibm.com writes:
[...]
A simple example to show this follows.
- Create a file with .d extension and mention the probe names in it with
provider name and marker name.
[...]
- Now create the probes.h and probes.o file :
$ dtrace -C -h -s probes.d -o probes.h
$
"zhangwei(Jovi)" writes:
> I'm pleased to announce that ktap release v0.1, this is the first official
> release of ktap project [...]
Congrats.
> = what's ktap?
>
>Because this is the first release, so there wouldn't include too
>much features, just contain several basic features
zhangwei(Jovi) jovi.zhang...@huawei.com writes:
I'm pleased to announce that ktap release v0.1, this is the first official
release of ktap project [...]
Congrats.
= what's ktap?
Because this is the first release, so there wouldn't include too
much features, just contain several
systemtap/dyninst Bugzilla component
(http://tinyurl.com/stapdyn-PR-list) if you want all the gory
details about the state of the feature.
= Contributors for this release
Dave Brolley, David Smith, Frank Ch. Eigler, Josh Stone, Lukas Berk,
Mark Wielaard, Masanari Iida*, Negreanu Marius Adrian, Serguei
/stapdyn-PR-list) if you want all the gory
details about the state of the feature.
= Contributors for this release
Dave Brolley, David Smith, Frank Ch. Eigler, Josh Stone, Lukas Berk,
Mark Wielaard, Masanari Iida*, Negreanu Marius Adrian, Serguei Makarov,
Timo Juhani Lindfors, Torsten Polle
Special
Hi -
> [...] How about creating trace_tick() in
> include/trace/events/timer.h and call it from tick_periodic() and
> tick_sched_handle(). [...]
Like this?
>From facee64445c0dcc717e99c474c5c7dcdd31b9a74 Mon Sep 17 00:00:00 2001
From: "Frank Ch. Eigler"
Date: Wed, 3 A
Hi -
[...] How about creating trace_tick() in
include/trace/events/timer.h and call it from tick_periodic() and
tick_sched_handle(). [...]
Like this?
From facee64445c0dcc717e99c474c5c7dcdd31b9a74 Mon Sep 17 00:00:00 2001
From: Frank Ch. Eigler f...@redhat.com
Date: Wed, 3 Apr 2013 10:35:21
Hi, Frederic -
> > How about this?
> >
> > Author: Frank Ch. Eigler
> > Date: Wed Apr 3 10:35:21 2013 -0400
> >
> > profiling: add profile_tick tracepoint
> > [...]
> It would be better not to tie this to CONFIG_PROFILING.
> A tracepoint
Hi, Frederic -
How about this?
Author: Frank Ch. Eigler f...@redhat.com
Date: Wed Apr 3 10:35:21 2013 -0400
profiling: add profile_tick tracepoint
[...]
It would be better not to tie this to CONFIG_PROFILING.
A tracepoint in update_process_times() instead would be great
1 - 100 of 233 matches
Mail list logo
