Skip to content

K
Kernel

openeuler / Kernel
大约 1 年 前同步成功

通知 5
Star 0
Fork 0
K
Kernel

体验新版 GitCode，发现更多精彩内容 >>

切换分支/标签
  1. 15 11月, 2019 10 次提交
  3. 13 11月, 2019 17 次提交
    • D
      tracing: Adding NULL checks for trace_array descriptor pointer · 953ae45a
      由 Divya Indi 提交于 
      As part of commit f45d1225 ("tracing: Kernel access to Ftrace
instances") we exported certain functions. Here, we are adding some additional
NULL checks to ensure safe usage by users of these APIs.

Link: http://lkml.kernel.org/r/1565805327-579-4-git-send-email-divya.indi@oracle.comSigned-off-by: NDivya Indi <divya.indi@oracle.com>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      953ae45a
    • D
      tracing: Verify if trace array exists before destroying it. · e585e646
      由 Divya Indi 提交于 
      A trace array can be destroyed from userspace or kernel. Verify if the
trace array exists before proceeding to destroy/remove it.

Link: http://lkml.kernel.org/r/1565805327-579-3-git-send-email-divya.indi@oracle.comReviewed-by: NAruna Ramakrishna <aruna.ramakrishna@oracle.com>
Signed-off-by: NDivya Indi <divya.indi@oracle.com>
[ Removed unneeded braces ]
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      e585e646
    • D
      tracing: Declare newly exported APIs in include/linux/trace.h · 2d6425af
      由 Divya Indi 提交于 
      Declare the newly introduced and exported APIs in the header file -
include/linux/trace.h. Moving previous declarations from
kernel/trace/trace.h to include/linux/trace.h.

Link: http://lkml.kernel.org/r/1565805327-579-2-git-send-email-divya.indi@oracle.comSigned-off-by: NDivya Indi <divya.indi@oracle.com>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      2d6425af
    • B
      tracing: Make internal ftrace events static · 6dff4d7d
      由 Ben Dooks 提交于 
      The event_class_ftrace_##call and event_##call do not seem
to be used outside of trace_export.c so make them both static
to avoid a number of sparse warnings:

kernel/trace/trace_entries.h:59:1: warning: symbol 'event_class_ftrace_function' was not declared. Should it be static?
kernel/trace/trace_entries.h:59:1: warning: symbol '__event_function' was not declared. Should it be static?
kernel/trace/trace_entries.h:77:1: warning: symbol 'event_class_ftrace_funcgraph_entry' was not declared. Should it be static?
kernel/trace/trace_entries.h:77:1: warning: symbol '__event_funcgraph_entry' was not declared. Should it be static?
kernel/trace/trace_entries.h:93:1: warning: symbol 'event_class_ftrace_funcgraph_exit' was not declared. Should it be static?
kernel/trace/trace_entries.h:93:1: warning: symbol '__event_funcgraph_exit' was not declared. Should it be static?
kernel/trace/trace_entries.h:129:1: warning: symbol 'event_class_ftrace_context_switch' was not declared. Should it be static?
kernel/trace/trace_entries.h:129:1: warning: symbol '__event_context_switch' was not declared. Should it be static?
kernel/trace/trace_entries.h:149:1: warning: symbol 'event_class_ftrace_wakeup' was not declared. Should it be static?
kernel/trace/trace_entries.h:149:1: warning: symbol '__event_wakeup' was not declared. Should it be static?
kernel/trace/trace_entries.h:171:1: warning: symbol 'event_class_ftrace_kernel_stack' was not declared. Should it be static?
kernel/trace/trace_entries.h:171:1: warning: symbol '__event_kernel_stack' was not declared. Should it be static?
kernel/trace/trace_entries.h:191:1: warning: symbol 'event_class_ftrace_user_stack' was not declared. Should it be static?
kernel/trace/trace_entries.h:191:1: warning: symbol '__event_user_stack' was not declared. Should it be static?
kernel/trace/trace_entries.h:214:1: warning: symbol 'event_class_ftrace_bprint' was not declared. Should it be static?
kernel/trace/trace_entries.h:214:1: warning: symbol '__event_bprint' was not declared. Should it be static?
kernel/trace/trace_entries.h:230:1: warning: symbol 'event_class_ftrace_print' was not declared. Should it be static?
kernel/trace/trace_entries.h:230:1: warning: symbol '__event_print' was not declared. Should it be static?
kernel/trace/trace_entries.h:247:1: warning: symbol 'event_class_ftrace_raw_data' was not declared. Should it be static?
kernel/trace/trace_entries.h:247:1: warning: symbol '__event_raw_data' was not declared. Should it be static?
kernel/trace/trace_entries.h:262:1: warning: symbol 'event_class_ftrace_bputs' was not declared. Should it be static?
kernel/trace/trace_entries.h:262:1: warning: symbol '__event_bputs' was not declared. Should it be static?
kernel/trace/trace_entries.h:277:1: warning: symbol 'event_class_ftrace_mmiotrace_rw' was not declared. Should it be static?
kernel/trace/trace_entries.h:277:1: warning: symbol '__event_mmiotrace_rw' was not declared. Should it be static?
kernel/trace/trace_entries.h:298:1: warning: symbol 'event_class_ftrace_mmiotrace_map' was not declared. Should it be static?
kernel/trace/trace_entries.h:298:1: warning: symbol '__event_mmiotrace_map' was not declared. Should it be static?
kernel/trace/trace_entries.h:322:1: warning: symbol 'event_class_ftrace_branch' was not declared. Should it be static?
kernel/trace/trace_entries.h:322:1: warning: symbol '__event_branch' was not declared. Should it be static?
kernel/trace/trace_entries.h:343:1: warning: symbol 'event_class_ftrace_hwlat' was not declared. Should it be static?
kernel/trace/trace_entries.h:343:1: warning: symbol '__event_hwlat' was not declared. Should it be static?

Link: http://lkml.kernel.org/r/20191015121012.18824-1-ben.dooks@codethink.co.ukSigned-off-by: NBen Dooks <ben.dooks@codethink.co.uk>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      6dff4d7d
    • S
      tracing: Use CONFIG_PREEMPTION · 9c34fc4b
      由 Sebastian Andrzej Siewior 提交于 
      CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
Both PREEMPT and PREEMPT_RT require the same functionality which today
depends on CONFIG_PREEMPT.

Add additional header output for PREEMPT_RT.
Link: http://lkml.kernel.org/r/20191015191821.11479-34-bigeasy@linutronix.de

Cc: Ingo Molnar <mingo@redhat.com>
Signed-off-by: NSebastian Andrzej Siewior <bigeasy@linutronix.de>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      9c34fc4b
    • V
      preemptirq_delay_test: Add the burst feature and a sysfs trigger · 79393723
      由 Viktor Rosendahl (BMW) 提交于 
      This burst feature enables the user to generate a burst of
preempt/irqsoff latencies. This makes it possible to test whether we
are able to detect latencies that systematically occur very close to
each other.

The maximum burst size is 10. We also create 10 identical test
functions, so that we get 10 different backtraces; this is useful
when we want to test whether we can detect all the latencies in a
burst. Otherwise, there would be no easy way of differentiating
between which latency in a burst was captured by the tracer.

In addition, there is a sysfs trigger, so that it's not necessary to
reload the module to repeat the test. The trigger will appear as
/sys/kernel/preemptirq_delay_test/trigger in sysfs.

Link: http://lkml.kernel.org/r/20191008220824.7911-3-viktor.rosendahl@gmail.comReviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: NViktor Rosendahl (BMW) <viktor.rosendahl@gmail.com>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      79393723
    • V
      ftrace: Implement fs notification for tracing_max_latency · 91edde2e
      由 Viktor Rosendahl (BMW) 提交于 
      This patch implements the feature that the tracing_max_latency file,
e.g. /sys/kernel/debug/tracing/tracing_max_latency will receive
notifications through the fsnotify framework when a new latency is
available.

One particularly interesting use of this facility is when enabling
threshold tracing, through /sys/kernel/debug/tracing/tracing_thresh,
together with the preempt/irqsoff tracers. This makes it possible to
implement a user space program that can, with equal probability,
obtain traces of latencies that occur immediately after each other in
spite of the fact that the preempt/irqsoff tracers operate in overwrite
mode.

This facility works with the hwlat, preempt/irqsoff, and wakeup
tracers.

The tracers may call the latency_fsnotify() from places such as
__schedule() or do_idle(); this makes it impossible to call
queue_work() directly without risking a deadlock. The same would
happen with a softirq,  kernel thread or tasklet. For this reason we
use the irq_work mechanism to call queue_work().

This patch creates a new workqueue. The reason for doing this is that
I wanted to use the WQ_UNBOUND and WQ_HIGHPRI flags.  My thinking was
that WQ_UNBOUND might help with the latency in some important cases.

If we use:

queue_work(system_highpri_wq, &tr->fsnotify_work);

then the work will (almost) always execute on the same CPU but if we are
unlucky that CPU could be too busy while there could be another CPU in
the system that would be able to process the work soon enough.

queue_work_on() could be used to queue the work on another CPU but it
seems difficult to select the right CPU.

Link: http://lkml.kernel.org/r/20191008220824.7911-2-viktor.rosendahl@gmail.comReviewed-by: NJoel Fernandes (Google) <joel@joelfernandes.org>
Signed-off-by: NViktor Rosendahl (BMW) <viktor.rosendahl@gmail.com>
[ Added max() to have one compare for max latency ]
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      91edde2e
    • S
      ftrace: Add information on number of page groups allocated · da537f0a
      由 Steven Rostedt (VMware) 提交于 
      Looking for ways to shrink the size of the dyn_ftrace structure, knowing the
information about how many pages and the number of groups of those pages, is
useful in working out the best ways to save on memory.

This adds one info print on how many groups of pages were used to allocate
the ftrace dyn_ftrace structures, and also shows the number of pages and
groups in the dyn_ftrace_total_info (which is used for debugging).
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      da537f0a
    • J
      ftrace/x86: Tell objtool to ignore nondeterministic ftrace stack layout · 77ac117b
      由 Josh Poimboeuf 提交于 
      Objtool complains about the new ftrace direct trampoline code:

  arch/x86/kernel/ftrace_64.o: warning: objtool: ftrace_regs_caller()+0x190: stack state mismatch: cfa1=7+16 cfa2=7+24

Typically, code has a deterministic stack layout, such that at a given
instruction address, the stack frame size is always the same.

That's not the case for the new ftrace_regs_caller() code after it
adjusts the stack for the direct case.  Just plead ignorance and assume
it's always the non-direct path.  Note this creates a tiny window for
ORC to get confused.

Link: http://lkml.kernel.org/r/20191108225100.ea3bhsbdf6oerj6g@trebleReported-by: NSteven Rostedt <rostedt@goodmis.org>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      77ac117b
    • S
      ftrace/x86: Add a counter to test function_graph with direct · a3ad1a7e
      由 Steven Rostedt (VMware) 提交于 
      As testing for direct calls from the function graph tracer adds a little
overhead (which is a lot when tracing every function), add a counter that
can be used to test if function_graph tracer needs to test for a direct
caller or not.

It would have been nicer if we could use a static branch, but the static
branch logic fails when used within the function graph tracer trampoline.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      a3ad1a7e
    • S
      ftrace/x86: Add register_ftrace_direct() for custom trampolines · 562955fe
      由 Steven Rostedt (VMware) 提交于 
      Enable x86 to allow for register_ftrace_direct(), where a custom trampoline
may be called directly from an ftrace mcount/fentry location.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      562955fe
    • S
      ftrace/selftests: Update the direct call selftests to test two direct calls · ed9dafeb
      由 Steven Rostedt (VMware) 提交于 
      The register_ftrace_direct() takes a different path if there's already a
direct call registered, but this was not tested in the self tests. Now that
there's a second direct caller test module, we can use this to test not only
one direct caller, but two.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      ed9dafeb
    • S
      ftrace: Add another example of register_ftrace_direct() use case · 156473a0
      由 Steven Rostedt (VMware) 提交于 
      Add another module sample that registers a direct trampoline to a function
via register_ftrace_direct(). Having another module that does this allows to
test the use case of multiple direct callers registered, as more than one
direct caller goes into another path, and is needed to perform proper
testing of the register_ftrace_direct() call.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      156473a0
    • S
      ftrace/selftest: Add tests to test register_ftrace_direct() · 646f01cc
      由 Steven Rostedt (VMware) 提交于 
      Add two test cases that test the new ftrace direct functionality if the
ftrace-direct sample module is available. One test case tests against each
available tracer (function, function_graph, mmiotrace, etc), and the other
test tests against a kprobe at the same location as the direct caller. Both
tests follow the same pattern of testing combinations:

  enable test (either the tracer or the kprobe)
  load direct function module
  unload direct function module
  disable test

  enable test
  load direct function module
  disable test
  unload direct function module

  load direct function module
  enable test
  disable test
  unload direct function module

  load direct function module
  enable test
  unload direct function module
  disable test

As most the bugs in development happened with various ways of enabling or
disabling the direct calls with function tracer in one of these
combinations.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      646f01cc
    • S
      ftrace: Add sample module that uses register_ftrace_direct() · b06457c8
      由 Steven Rostedt (VMware) 提交于 
      Add a sample module that shows a simple use case for
regsiter_ftrace_direct(), and how to use it.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      b06457c8
    • S
      ftrace: Add ftrace_find_direct_func() · 013bf0da
      由 Steven Rostedt (VMware) 提交于 
      As function_graph tracer modifies the return address to insert a trampoline
to trace the return of a function, it must be aware of a direct caller, as
when it gets called, the function's return address may not be at on the
stack where it expects. It may have to see if that return address points to
the a direct caller and adjust if it is.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      013bf0da
    • S
      ftrace: Add register_ftrace_direct() · 763e34e7
      由 Steven Rostedt (VMware) 提交于 
      Add the start of the functionality to allow other trampolines to use the
ftrace mcount/fentry/nop location. This adds two new functions:

 register_ftrace_direct() and unregister_ftrace_direct()

Both take two parameters: the first is the instruction address of where the
mcount/fentry/nop exists, and the second is the trampoline to have that
location called.

This will handle cases where ftrace is already used on that same location,
and will make it still work, where the registered direct called trampoline
will get called after all the registered ftrace callers are handled.

Currently, it will not allow for IP_MODIFY functions to be called at the
same locations, which include some kprobes and live kernel patching.

At this point, no architecture supports this. This is only the start of
implementing the framework.
Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      763e34e7
  5. 09 11月, 2019 2 次提交
  7. 04 11月, 2019 5 次提交
  9. 03 11月, 2019 6 次提交