| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Message-Id: <20080710132832.38cc5048.randy.dunlap@oracle.com>
Date: Thu, 10 Jul 2008 13:28:32 -0700
From: Randy Dunlap <randy.dunlap@...cle.com>
To: Elias Oltmanns <eo@...ensachen.de>
Cc: Steven Rostedt <rostedt@...dmis.org>,
LKML <linux-kernel@...r.kernel.org>, Ingo Molnar <mingo@...e.hu>,
Thomas Gleixner <tglx@...utronix.de>,
Peter Zijlstra <peterz@...radead.org>,
Clark Williams <clark.williams@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Jon Masters <jonathan@...masters.org>
Subject: Re: [PATCH] ftrace: Documentation
On Thu, 10 Jul 2008 21:59:01 +0200 Elias Oltmanns wrote:
> Steven Rostedt <rostedt@...dmis.org> wrote:
> > This is the long awaited ftrace.txt. It explains in quite detail how to
> > use ftrace and the various tracers.
> >
> > Signed-off-by: Steven Rostedt <srostedt@...hat.com>
>
> Exactly what I've just been looking for. Very nice.
>
> As I read through this enlightening peace, I took the liberty to make
> some comments where I thought I'd spotted some mistake. Note that I'm
> not a native English speaker nor familiar with all the terminology.
> Also, I didn't exactly scratch my head when I had a bad feeling about
> something but couldn't come up with a better idea straight away.
> Basically, I just skimmed through the lines because im interested in the
> matter.
>
> Anyway, here it goes:
[I'm dropping good comments, just making more comments.]
> > + set_ftrace_notrace: This has the opposite effect that
> > + set_ftrace_filter has. Any function that is added
> > + here will not be traced. If a function exists
> > + in both set_ftrace_filter and set_ftrace_notrace
>
> (comma)
>
> > + the function will _not_ bet traced.
be
> > + stacktrace - This is one of the options that changes the trace itself.
>
> change
changes :) [subject is "This", singular]
>
> > + When a trace is recorded, so is the stack of functions.
> > + This allows for back traces of trace sites.
> > +
> > +sched_switch
> > +------------
> > +
> > +This tracer simply records schedule switches. Here's an example
> > +on how to implement it.
of
>
> use?
>
> [...]
> > +Here we traced a 50 microsecond latency. But we also see all the
> > +functions that were called during that time. Note that enabling
>
> by enabling?
>
> > +function tracing we endure an added overhead. This overhead may
>
> (comma)
>
> > +extend the latency times. But never the less, this trace has provided
nevertheless,
> > +some very helpful debugging.
>
> debugging information?
>
> > +
> > +
> > +preemptoff
> > +----------
> > +
> > +When preemption is disabled we may be able to receive interrupts but
>
> (comma)
>
> > +the task can not be preempted and a higher priority task must wait
cannot
> > +for preemption to be enabled again before it can preempt a lower
> > +priority task.
> > +
> > +The preemptoff tracer traces the places that disables preemption.
>
> disable
>
> > +Like the irqsoff, it records the maximum latency that preemption
> > +was disabled. The control of preemptoff is much like the irqsoff.
> > +Since this tracer only deals with RT tasks, we will run this slightly
> > +different than we did with the previous tracers. Instead of performing
differently
> > +an 'ls' we will run 'sleep 1' under 'chrt' which changes the
>
> (comma)
>
> > +priority of the task.
> [...]
> > +Where as the setting of the NEED_RESCHED bit happens on the
Whereas
> > +task's stack. But because we are in a hard interrupt, the test
^? That's not a complete sentence.
> > +is with the interrupts stack which has that to be false. We don't
interrupt
>
> ^^^^
> Superfluous that? Don't understand that sentence.
>
> > +see the 'N' until we switch back to the task's stack.
> [...]
> > +When dynamic ftrace is initialized, it calls kstop_machine to make it
^^ what is "it"?
> > +act like a uniprocessor so that it can freely modify code without
> > +worrying about other processors executing that same code. At
> > +initialization, the mcount calls are change to call a "record_ip"
>
> changed
>
> > +function. After this, the first time a kernel function is called,
> > +it has the calling address saved in a hash table.
> [...]
> > +Two files that contain to the enabling and disabling of recorded
> > +functions are:
>
> Can this be expressed somewhat differently?
or drop "to".
>
> > +
> > + set_ftrace_filter
> > +
> > +and
> > +
> > + set_ftrace_notrace
> > +
> > +A list of available functions that you can add to this files is listed
>
> these
>
> > +in:
> > +
> > + available_filter_functions
> [...]
> > +Perhaps this isn't enough. The filters also allow simple wild cards.
> > +Only the following is currently available
Only the following are currently available:
> > +
> > + <match>* - will match functions that begins with <match>
>
> begin
>
> > + *<match> - will match functions that end with <match>
> > + *<match>* - will match functions that have <match> in it
---
~Randy
Linux Plumbers Conference, 17-19 September 2008, Portland, Oregon USA
http://linuxplumbersconf.org/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists