s release
Aaron 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
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 g
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
> > the
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
ses a segment register.
(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
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
the top level linux Makefile:
KBUILD_CFLAGS += $(call cc-option, -fno-var-tracking-assignments)
= 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, Marti
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 and/o
nut butter 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,
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, 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 th
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 were
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"), kprobe.function("
details 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/
http://tinyurl.com/stapdyn-PR-list) if you want all the gory
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 Ce
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 of
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() step
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 is
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.
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 a
-by: Josh Stone
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
@@
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
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, 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 dt
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 secon
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
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.
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 m
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 -
>> 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 appro
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
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
> > event
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 kpro
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
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 l
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 doe
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 th
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
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" sys
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
co
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 pro
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 t
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 st
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
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 read
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 pr
"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 about
when the kernel backend is active
+ exception handling becomes completely broken in programs
instrumented by the current version of dyninst (PR14702)
+ command line interrupts are slightly mishandled (PR15049)
+ not all registers are made available on 32-bit x86 (PR15136)
See dyninst/README and
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, 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, Mel -
> > [...] git kernel developers
> > should use git systemtap, as has always been the case. [...]
>
> At one point in the past this used to be the case but then systemtap had to
> be compiled as part of automated tests across different kernel versions. It
> could have been worked aroun
Hi -
tytso wrote:
> So I tried to reproduce the problem, and so I installed systemtap
> (bleeding edge, since otherwise it won't work with development
> kernel), and then rebuilt a kernel with all of the necessary CONFIG
> options enabled:
>
> CONFIG_DEBUG_INFO, CONFIG_KPROBES, CONFIG_REL
Hi -
On Wed, Apr 03, 2013 at 02:49:53PM +0200, Frederic Weisbecker wrote:
> Sounds good, would you like to propose a version? We are also
> interested in a timer tick event tracepoint for dynticks debugging.
How about this?
Author: Frank Ch. Eigler
Date: Wed Apr 3 10:35:21 2013
Frederic Weisbecker writes:
> [...]
> Sometimes I don't mind keeping around code in the kernel for out of
> tree users, depending on the case. But in this specific matter we have
> more standard ways to do this kind of hook: kprobes, static
> tracepoints. A tracepoint on the timer tick would be u
Hi -
> [...]
> - add_taint(TAINT_DIE);
> + add_taint(TAINT_DIE, LOCKDEP_NOW_UNRELIABLE);
> [...]
If "UNRELIABLE" a good way to describe it - not DANGEROUS or
COUNTERPRODUCTIVE or something, then maybe lockdep *can* produce
reasonable results following such a taint. If the results are mer
Hi -
On Fri, Jan 18, 2013 at 09:24:55AM +0800, Jovi Zhang wrote:
> Let us continue this ktap topic in this thread :).
> ktap code is public available at github, please clone from:
> https://github.com/ktap/ktap.git
> [...]
Neat stuff. I have one set of initial observations: even with a nice
smal
Vivek Goyal writes:
> [...]
>> Can you please tell a bit more how this patch protect against direct
>> writing to the blocks?
>
> If you have loaded all the pages from disk and locked them in memory and
> verified the signature, then even if somebody modifies a block on disk
> it does not matter.
Hi -
bookjovi wrote:
> >> [...]
> >> ktap use lua language syntax and bytecode as initial implementation,
> >
> > Interesting approach. I recall we considered it way back when, but
> > rejected it for a couple of reasons, including the at-the-time
> > perceived unwelcomeness of a serious bytecod
bookjovi wrote:
> [...] This mail is RFC for discuss on a new dynamic tracing tool, I
> name it ktap. (only experimental project now)
Welcome to the problem domain!
> [...]
> what ktap differentiates with Systemtap is:
> [...]
> 2). ktap have good portability, because it compile source file
Oleg Nesterov writes:
> [...]
> Well, not sure this will help... but if you can reproduce this,
> may be you can identify the sender of the wrong SIGHUP at least.
>
> cd /sys/kernel/debug/tracing/
> echo "sig==1" >> events/signal/signal_generate/filter
> echo 1 >> options/stackt
Hi -
On Tue, Feb 12, 2008 at 10:20:10AM -0800, Andrew Morton wrote:
> [...] Bear in mind that one of the things you do with kgdb is to
> modify kernel memory [...]
Just for completeness, keep in mind that one can already
do these sorts of things on a batch basis using systemtap:
> int foo;
>
Andi Kleen <[EMAIL PROTECTED]> writes:
> [...] The kgdb code in git-x86#mm is right now is totally broken of
> course because the CFI annotations in assembler code are gone now,
> but they are needed for gdb use. [...]
This loss of CFI data is unfortunate for other potential consumers
too, such
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...] Since memory management is not my speciality, I would like to
> know if there are some implementation details I should be aware of
> for my LTTng userspace tracing buffers. Here is what I want to do
> [...]
Would you mind offering some justif
Hi -
On Wed, Jan 23, 2008 at 06:58:23PM +0100, Peter Zijlstra wrote:
> [...]
> > Is there an opportunity here to share effort with latencytop, and
> > ideally to use markers as much as possible for these event hooks?
>
> I'm still thinking latencytop should only record stack traces and do the
> r
Hi -
On Wed, Jan 23, 2008 at 12:11:07PM -0500, Steven Rostedt wrote:
> This patch adds latency tracing for critical timings
> (how long interrupts are disabled for).
> [...]
Is there an opportunity here to share effort with latencytop, and
ideally to use markers as much as possible for these even
Hi -
On Tue, Jan 22, 2008 at 11:17:40PM -0500, Jon Masters wrote:
> On Tue, 2008-01-22 at 22:10 -0500, Mathieu Desnoyers wrote:
> > [...]
> > > > Is this an attempt to not set a marker for proprietary modules? [...]
> > >
> > > I can't seem to find any discussion about this aspect. If this is th
Jon Masters <[EMAIL PROTECTED]> writes:
> I notice in module.c:
>
> #ifdef CONFIG_MARKERS
> if (!mod->taints)
> marker_update_probe_range(mod->markers,
> mod->markers + mod->num_markers, NULL, NULL);
> #endif
>
> Is this an attempt to not set a marker for
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> Török Edwin wrote:
>> [...]
>> P.S.: LatencyTop could have a feature to ask for more details on unknown
>> latency reasons, and it would generate a systemtap script itself, that
>> would show the backtraces to help figure out whats going on.
>
> I've
Hi -
On Fri, Jan 18, 2008 at 10:55:27PM -0500, Steven Rostedt wrote:
> [...]
> > All this complexity is to be justified by keeping the raw prev/next
> > pointers from being sent to a naive tracer? It seems to me way out of
> > proportion.
>
> Damn, and I just blew away all my marker code for som
Hi -
On Fri, Jan 18, 2008 at 06:19:29PM -0500, Mathieu Desnoyers wrote:
> [...]
> Almost.. I would add :
>
> static int trace_switch_to_enabled;
>
> > static inline trace_switch_to(struct task_struct *prev,
> > struct task_struct *next)
> > {
> if (likely(!trace_switch_to
Hi -
On Fri, Jan 18, 2008 at 05:49:19PM -0500, Steven Rostedt wrote:
> [...]
> > But I have not seen a lot of situations where that kind of glue-code was
> > needed, so I think it makes sense to keep markers simple to use and
> > efficient for the common case.
> >
> > Then, in this glue-code, we c
Hi -
On Fri, Jan 18, 2008 at 02:33:34PM -0800, Arjan van de Ven wrote:
> [...]
> > Can you suggest of some reason why all this instrumentation could
> > not be in the form of standard markers (perhaps conditionally
> > compiled out if necessary)?
>
> sure. Every instrumentation you see is of the
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> This patch contains the first set of instrumentations for latencytop;
> each instrumentation needs to be evaluated for usefulness before this
> can go into mainline; posting here just to show how the infrastructure
> can be used
> [...]
Can you sugge
Hi -
On Thu, Jan 17, 2008 at 03:08:33PM -0500, Steven Rostedt wrote:
> [...]
> + trace_mark(kernel_sched_schedule,
> + "prev_pid %d next_pid %d prev_state %ld",
> + prev->pid, next->pid, prev->state);
> [...]
> But...
>
> Tracers that want to do a bit more work,
Steven Rostedt <[EMAIL PROTECTED]> writes:
> The following patch series brings to vanilla Linux a bit of the RT kernel
> trace facility. This incorporates the "-pg" profiling option of gcc
> that will call the "mcount" function for all functions called in
> the kernel.
> [...]
> [Future:] SystemTa
Hi -
On Wed, Jan 02, 2008 at 06:01:57PM +0100, Ingo Molnar wrote:
> [...]
> well, -freorder-blocks seems to be default-enabled at -O2 on gcc 4.2, so
> we should already be getting that, right?
Right.
> [...] So it would be nice if we could collect all this offline code
> and stuff it away into
Hi -
On Wed, Jan 02, 2008 at 01:47:34PM +0100, Ingo Molnar wrote:
> [...]
> > FWIW, I'm not keen about the format strings either, but they don't
> > constitute a performance hit beyond an additional parameter. It does
> > not need to actually get parsed at run time.
>
> "only" an additional pa
Ingo Molnar <[EMAIL PROTECTED]> writes:
> [...] Firstly, why on earth does a full format string have to be
> passed in for something as simple as a CPU id? This way we basically
> codify it forever that tracing _has_ to be expensive when
> enabled. [...]
FWIW, I'm not keen about the format strin
Stephane Eranian <[EMAIL PROTECTED]> writes:
> [...]
>> > [...] AFAIK, there is no single call to stop T1 and wait until it
>> > is completely off the CPU, unless we go through the (internal)
>> > ptrace interface.
>>
>> The utrace code supports this style of thread manipulation better
>> than p
Stephane Eranian <[EMAIL PROTECTED]> writes:
> [...] AFAIK, there is no single call to stop T1 and wait until it
> is completely off the CPU, unless we go through the (internal)
> ptrace interface.
The utrace code supports this style of thread manipulation better
than ptrace.
- FChE
--
To unsu
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> This is an RFC for addition of a new thread flag, TIF_KERNEL_TRACE, to each
> architecture to activate system-wide system call tracing.
> [...]
Instead of creating a new flag, could you overload TIF_SYSCALL_TRACE,
putting the marker into syscall_tra
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> I think this is complete overkill. We should rather get one proper
> tracing infrastructure in tree instead of having multiple hacking ones
> in different places. Yes, please consider this a NACK ;-)
Multiple handlers for markers makes exactly as
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...]
>> > We would like to be able to tell which swap file the information has
>> > been written to/read from at any given time during the trace.
>>
>> Oh, tracing is expected to be on at all times? I figured someone would
>> encounter a problem,
"David J. Wilder" <[EMAIL PROTECTED]> writes:
> This patch adds several markers around semaphore primitives. Along
> with a tracing application this patch can be useful for measuring
> kernel semaphore usage and contention. [...]
In order to evaluate the permanent placement of markers, more
in
Hi -
On Wed, Oct 31, 2007 at 12:36:24PM -0400, Mathieu Desnoyers wrote:
> [...] That's right, Systemtap uses symbols, thanks for the
> clarification. But my point is still valid: SystemTAP expects
> function names and argument names to stay unchanged, therefore using
> the kernel code itself as
Hi -
On Wed, Oct 31, 2007 at 09:29:07AM -0700, Arjan van de Ven wrote:
> [...]
> > This misstates the details. What systemtap has out-of-tree is a list
> > of kernel function names (and parameter names), not addresses. This
> > list does change somewhat with kernel versions, but we generally kee
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...] SystemTAP, for instance, does it out of tree by keeping a
> separate list of address where kprobes must be installed. It does
> the job on a distribution kernel maintainer perspective (Redhat),
> since they freeze to a particular kernel versio
Hi -
On Thu, Oct 25, 2007 at 03:17:22PM -0400, Mathieu Desnoyers wrote:
> [...]
> Since gcc is required to build the systemtap probes on the development
> marchine, I don't see why it would be much harder to also require prople
> to install drawf ? Or maybe the "crash" tool ?
The crash tool requi
Hi -
I wrote:
> [...]
> > The marker metadata must be stored in at least one place in the kernel
> > image - this just happens to be a convenient one that David Smith's
> > recent systemtap code used. Without it, we'd probably have to do a
> > more complicated search, following the pointers with
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
>> [...]
>> > I totally agree with Ingo here. Having a basic instrumentation that is
>> > enabled by default will help to identify code paths causing unexpected
>> > delays in the kernel. [...]
>
>> It is. See: CONFIG_VM_EVENT_COUNTERS and all the oth
Hi -
On Fri, Sep 21, 2007 at 08:58:19AM -0400, Mathieu Desnoyers wrote:
> [...]
> > > Current systemtap marker support code relies on the __markers_strings
> > > section.
> > Let users know that in comment above section definition in ld script.
> [...]
> /* Markers: strings (used by System
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...] Do you think I should also remove the __markers_strings
> section from here ?
Current systemtap marker support code relies on the __markers_strings
section.
- FChE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Steven Rostedt <[EMAIL PROTECTED]> writes:
> [...]
> + * [...] We don't need to grab
> + * any locks, we just keep trying until get all the
> + * calculations together in one state.
> + *
> + * In fact, we __cant__ grab any locks. T
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...]
> +A marker placed in your code provides a hook to call a function (probe) that
> +you can provide at runtime. A marker can be "on" (a probe is connected to it)
> +or "off" (no probe is attached). When a marker is "off" it has no
> +effect. [.
Noah Watkins <[EMAIL PROTECTED]> writes:
> [...]
> The locks are aquired and released in each _start and _end marker, so
> the equilibrium is not a issue.
But it becomes an issue should preemption, or control flow upset such
as an early return or recursion, occurs between the start and end
marker
1 - 100 of 123 matches
Mail list logo
