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 -
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
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
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;
>
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
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
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
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
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 -
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, 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 -
> [...] 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
"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
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 -
> [...]
> - 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
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 -
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
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
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
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 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 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
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
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
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
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 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
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
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
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
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
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,
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
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,
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
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
"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 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
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 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
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
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> [...]
> The problem is also in _stp_print_flush, not *only* in relay code:
> void _stp_print_flush (void)
> ...
> spin_lock(&_stp_print_lock);
> ...
> spin_unlock(&_stp_print_lock);
>
> Those will turn
Hi -
On Thu, Jul 26, 2007 at 11:02:26AM -0400, Mathieu Desnoyers wrote:
> [...]
> > > The problem is also in _stp_print_flush, not *only* in relay code:
> > > void _stp_print_flush (void)
> > > ...
> > > spin_lock(&_stp_print_lock);
> > > spin_unlock(&_stp_print_loc
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
Christoph Lameter <[EMAIL PROTECTED]> writes:
> Simple performance counters are a way to measure the performance on
> code paths in the Linux kernel. Code must be instrumented with calls
> that signal the start and the stop of a measurement. [...]
For what it's worth, this kind of measurement w
Arjan van de Ven <[EMAIL PROTECTED]> writes:
> [...]
> It does not matter [whose] code gets merged.
> What matters is that the problem gets solved and that the Linux kernel
> innovates forward.
> [...]
This attitude has risks over the long term, if outsiders with fresh
ideas are discouraged. Ri
Hi -
> My concern is that only "get my line of code merged" is seen as "the
> ultimate thing". It's more than that. Linux is about collaboration [...]
Unfortunately, this spirit of collaboration sometimes gets lost in
practice when feedback is asymmetric, obnoxious, or absent.
- FChE
-
To unsubs
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. [.
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:
> [...]
> It would be nice to push the study of the kprobes debug trap handler so it can
> become possible to use it to put breakpoints in trap handlers. For now,
> kprobes
> refuses to insert breakpoints in __kprobes marked functions. However, as we
[EMAIL PROTECTED] writes:
> I'm experiencing extreme lags during disk writes. [...]
Wacky idea: "ionice -n 7 -c 2" down the pdflush/swapd kernel threads.
- FChE
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo
akpm wrote:
> [...] And what can I do with these markers? And once I've done it,
> are there any userspace applications I can use to get the data out
> in human-usable form? [...]
The LTTng user-space programs use it today. Systemtap used to support
the earlier marker prototype and will be r
Jeff Muizelaar <[EMAIL PROTECTED]> writes:
> I've built a tool with the goal of logging mmio writes and reads by
> device drivers. See http://nouveau.freedesktop.org/wiki/MmioTrace.
FWIW, this is exactly a type of add-on trace patch that could be
mooted by adoption of the ltt/systemtap "marker" f
Hi -
On Fri, Feb 16, 2007 at 09:03:23PM +0100, Andi Kleen wrote:
> > We in systemtap land have the same problem, and so far made do with
> > slightly postprocessed per-cpu TSC values.
>
> 90+% likely you're not solving your problem correctly this way.
Yes, it was done as a last resort.
We need
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> This patch adds the Linux Kernel Markers [...]
> Signed-off-by : Mathieu Desnoyers <[EMAIL PROTECTED]>
If it helps,
Acked-by: Frank Ch. Eigler <[EMAIL PROTECTED]>
One question:
> [...]
&g
Hi -
On Tue, Nov 28, 2006 at 05:40:36AM +, Christoph Hellwig wrote:
> [...]
> > > Are you sure the license_gplok check is necessary here? We should
> > > consider encouraging non-gpl module writers to instrument their code,
> > > to give users a slightly better chance of debugging problems.
Adrian Bunk <[EMAIL PROTECTED]> writes:
> [...]
> profiling = debugging of performance problems
Indeed.
> My words were perhaps a bit sloppy, but profiling isn't part of
> normal operation and if people use a separate kernel for such
> purposes we don't need infrastructure for reducing performan
Hi, Adrian -
On Sat, Jul 07, 2007 at 07:01:57PM +0200, Adrian Bunk wrote:
> [...]
> > Things are not so simple. One might not know that one has a
> > performance problem until one tries some analysis tools. Rebooting
> > into different kernels just to investigate does not work generally [...]
>
"Zhang, Yanmin" <[EMAIL PROTECTED]> writes:
> [...]
> > > 2) Delete lock. [..]
> > > In addition, the result is for performance data collection, so it's
> > > unnecessary to add such lock.
> > Not sure that's a good idea. People expect their performance counts
> > to be accurate too. [...]
> [...]
Mathieu Desnoyers <[EMAIL PROTECTED]> writes:
> This updated version of the Linux Kernel Markers mostly adds a unique 16 bits
> per marker ID and a per-probe marker group. [...]
Could you motivate this part better? It is not covered in the
documentation patch.
It seems to be a way of having a m
"Michael K. Edwards" <[EMAIL PROTECTED]> writes:
> Thanks Alan, this is really helpful -- I'll see if I can figure out
> kprobes. It is not immediately obvious to me how to use them to
> trace function calls in userspace, but I'll read up.
kprobes does not work with userspace. We in systemtap l
Christoph Hellwig <[EMAIL PROTECTED]> writes:
> [...]
> > merge it in the first place?
>
> It's very nice to poke deep into the kernel for development purposes.
> For example for the spu scheduler work I'm doing currently I have
> a module using kprobes (note the systemtap crap because it's big,
Hi -
On Mon, Apr 16, 2007 at 11:36:05PM +0200, Andi Kleen wrote:
> Christoph Hellwig <[EMAIL PROTECTED]> writes:
> > and [systemtap] does a lot of really wrong things in it's
> > runtime). [...]
(Thanks, Christoph, for at least a few specifics. Some of them have
already been dealt with in the re
Hi -
Keshavamurthy, Anil S wrote:
> I agree with Christoph that the interface is horrible and error prone.
Really? What possible problems can occur? The worst that occurs to
me is that if someone forgets to call the commit function, the kprobes
will still be disabled, but memory won't be recycl
Hi -
"Keshavamurthy, Anil S" <[EMAIL PROTECTED]> writes:
> [...]
> > Really? What possible problems can occur? The worst that occurs
> > to me is that if someone forgets to call the commit function, the
> > kprobes will still be disabled, but memory won't be recycled for a
> > while. [...]
>
Andrew Morton <[EMAIL PROTECTED]> writes:
> [...] I am told that the systemtap developers plan to (or are)
> using this infrastructure.
Indeed.
> If correct: what is their reason for preferring it over kprobes?
> [...]
It's not a preference - it's more of a supplement. It's helpful when
some
Andi Kleen <[EMAIL PROTECTED]> writes:
> [...] The SystemTAP project also plan to use this type of
> > infrastructure to trace sites hard to instrument. The Linux Kernel
> > Markers has the support of Frank C. Eigler, author of their current
> > marker alternative [...]
>
> All of the above don'
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, 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 -
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
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
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
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
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
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
-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, 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
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 -
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
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
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
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
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
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, 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
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
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
> >
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 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
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
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
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, 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
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
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
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
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 -
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
1 - 100 of 123 matches
Mail list logo
