1. 05 7月, 2016 1 次提交
  2. 20 6月, 2016 1 次提交
  3. 21 5月, 2016 1 次提交
    • S
      ftrace: Don't disable irqs when taking the tasklist_lock read_lock · 6112a300
      Soumya PN 提交于
      In ftrace.c inside the function alloc_retstack_tasklist() (which will be
      invoked when function_graph tracing is on) the tasklist_lock is being
      held as reader while iterating through a list of threads. Here the lock
      is being held as reader with irqs disabled. The tasklist_lock is never
      write_locked in interrupt context so it is safe to not disable interrupts
      for the duration of read_lock in this block which, can be significant,
      given the block of code iterates through all threads. Hence changing the
      code to call read_lock() and read_unlock() instead of read_lock_irqsave()
      and read_unlock_irqrestore().
      
      A similar change was made in commits: 8063e41d ("tracing: Change
      syscall_*regfunc() to check PF_KTHREAD and use for_each_process_thread()")'
      and 3472eaa1 ("sched: normalize_rt_tasks(): Don't use _irqsave for
      tasklist_lock, use task_rq_lock()")'
      
      Link: http://lkml.kernel.org/r/1463500874-77480-1-git-send-email-soumya.p.n@hpe.comSigned-off-by: NSoumya PN <soumya.p.n@hpe.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      6112a300
  4. 27 4月, 2016 1 次提交
    • T
      ftrace: Match dot symbols when searching functions on ppc64 · 7132e2d6
      Thiago Jung Bauermann 提交于
      In the ppc64 big endian ABI, function symbols point to function
      descriptors. The symbols which point to the function entry points
      have a dot in front of the function name. Consequently, when the
      ftrace filter mechanism searches for the symbol corresponding to
      an entry point address, it gets the dot symbol.
      
      As a result, ftrace filter users have to be aware of this ABI detail on
      ppc64 and prepend a dot to the function name when setting the filter.
      
      The perf probe command insulates the user from this by ignoring the dot
      in front of the symbol name when matching function names to symbols,
      but the sysfs interface does not. This patch makes the ftrace filter
      mechanism do the same when searching symbols.
      
      Fixes the following failure in ftracetest's kprobe_ftrace.tc:
      
        .../kprobe_ftrace.tc: line 9: echo: write error: Invalid argument
      
      That failure is on this line of kprobe_ftrace.tc:
      
        echo _do_fork > set_ftrace_filter
      
      This is because there's no _do_fork entry in the functions list:
      
        # cat available_filter_functions | grep _do_fork
        ._do_fork
      
      This change introduces no regressions on the perf and ftracetest
      testsuite results.
      
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: linuxppc-dev@lists.ozlabs.org
      Signed-off-by: NThiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
      Acked-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NMichael Ellerman <mpe@ellerman.id.au>
      7132e2d6
  5. 14 4月, 2016 1 次提交
  6. 23 3月, 2016 1 次提交
  7. 18 3月, 2016 3 次提交
  8. 18 2月, 2016 1 次提交
  9. 08 1月, 2016 2 次提交
    • Q
      ftrace: Fix the race between ftrace and insmod · 5156dca3
      Qiu Peiyang 提交于
      We hit ftrace_bug report when booting Android on a 64bit ATOM SOC chip.
      Basically, there is a race between insmod and ftrace_run_update_code.
      
      After load_module=>ftrace_module_init, another thread jumps in to call
      ftrace_run_update_code=>ftrace_arch_code_modify_prepare
                              =>set_all_modules_text_rw, to change all modules
      as RW. Since the new module is at MODULE_STATE_UNFORMED, the text attribute
      is not changed. Then, the 2nd thread goes ahead to change codes.
      However, load_module continues to call complete_formation=>set_section_ro_nx,
      then 2nd thread would fail when probing the module's TEXT.
      
      The patch fixes it by using notifier to delay the enabling of ftrace
      records to the time when module is at state MODULE_STATE_COMING.
      
      Link: http://lkml.kernel.org/r/567CE628.3000609@intel.comSigned-off-by: NQiu Peiyang <peiyangx.qiu@intel.com>
      Signed-off-by: NZhang Yanmin <yanmin.zhang@intel.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      5156dca3
    • S
      ftrace: Add infrastructure for delayed enabling of module functions · b7ffffbb
      Steven Rostedt (Red Hat) 提交于
      Qiu Peiyang pointed out that there's a race when enabling function tracing
      and loading a module. In order to make the modifications of converting nops
      in the prologue of functions into callbacks, the text needs to be converted
      from read-only to read-write. When enabling function tracing, the text
      permission is updated, the functions are modified, and then they are put
      back.
      
      When loading a module, the updates to convert function calls to mcount is
      done before the module text is set to read-only. But after it is done, the
      module text is visible by the function tracer. Thus we have the following
      race:
      
      	CPU 0			CPU 1
      	-----			-----
         start function tracing
         set text to read-write
      			     load_module
      			     add functions to ftrace
      			     set module text read-only
      
         update all functions to callbacks
         modify module functions too
         < Can't it's read-only >
      
      When this happens, ftrace detects the issue and disables itself till the
      next reboot.
      
      To fix this, a new DISABLED flag is added for ftrace records, which all
      module functions get when they are added. Then later, after the module code
      is all set, the records will have the DISABLED flag cleared, and they will
      be enabled if any callback wants all functions to be traced.
      
      Note, this doesn't add the delay to later. It simply changes the
      ftrace_module_init() to do both the setting of DISABLED records, and then
      immediately calls the enable code. This helps with testing this new code as
      it has the same behavior as previously. Another change will come after this
      to have the ftrace_module_enable() called after the text is set to
      read-only.
      
      Cc: Qiu Peiyang <peiyangx.qiu@intel.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      b7ffffbb
  10. 24 12月, 2015 6 次提交
  11. 26 11月, 2015 3 次提交
    • S
      ftrace: Show all tramps registered to a record on ftrace_bug() · 39daa7b9
      Steven Rostedt (Red Hat) 提交于
      When an anomaly is detected in the function call modification code,
      ftrace_bug() is called to disable function tracing as well as give any
      information that may help debug the problem. Currently, only the first found
      trampoline that is attached to the failed record is reported. Instead, show
      all trampolines that are hooked to it.
      
      Also, not only show the ops pointer but also report the function it calls.
      
      While at it, add this info to the enabled_functions debug file too.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      39daa7b9
    • S
      ftrace: Add variable ftrace_expected for archs to show expected code · b05086c7
      Steven Rostedt (Red Hat) 提交于
      When an anomaly is found while modifying function code, ftrace_bug() is
      called which disables the function tracing infrastructure and reports
      information about what failed. If the code that is to be replaced does not
      match what is expected, then actual code is shown. Currently there is no
      arch generic way to show what was expected.
      
      Add a new variable pointer calld ftrace_expected that the arch code can set
      to point to what it expected so that ftrace_bug() can report the actual text
      as well as the text that was expected to be there.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      b05086c7
    • S
      ftrace: Add new type to distinguish what kind of ftrace_bug() · 02a392a0
      Steven Rostedt (Red Hat) 提交于
      The ftrace function hook utility has several internal checks to make sure
      that whatever it modifies is exactly what it expects to be modifying. This
      is essential as modifying running code can be extremely dangerous to the
      system.
      
      When an anomaly is detected, ftrace_bug() is called which sends a splat to
      the console and disables function tracing. There's some extra information
      that is printed to help diagnose the issue.
      
      One thing that is missing though is output of what ftrace was doing at the
      time of the crash. Was it updating a call site or perhaps converting a call
      site to a nop? A new global enum variable is created to state what ftrace
      was doing at the time of the anomaly, and this is reported in ftrace_bug().
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      02a392a0
  12. 21 10月, 2015 2 次提交
    • D
      ftrace: add module globbing · 0b507e1e
      Dmitry Safonov 提交于
      Extend module command for function filter selection with globbing.
      It uses the same globbing as function filter.
      
        sh# echo '*alloc*:mod:*' > set_ftrace_filter
      
      Will trace any function with the letters 'alloc' in the name in any
      module but not in kernel.
      
        sh# echo '!*alloc*:mod:ipv6' >> set_ftrace_filter
      
      Will prevent from tracing functions with 'alloc' in the name from module
      ipv6 (do not forget to append to set_ftrace_filter file).
      
        sh# echo '*alloc*:mod:!ipv6' > set_ftrace_filter
      
      Will trace functions with 'alloc' in the name from kernel and any
      module except ipv6.
      
        sh# echo '*alloc*:mod:!*' > set_ftrace_filter
      
      Will trace any function with the letters 'alloc' in the name only from
      kernel, but not from any module.
      
        sh# echo '*:mod:!*' > set_ftrace_filter
      or
        sh# echo ':mod:!' > set_ftrace_filter
      
      Will trace every function in the kernel, but will not trace functions
      from any module.
      
        sh# echo '*:mod:*' > set_ftrace_filter
      or
        sh# echo ':mod:' > set_ftrace_filter
      
      As the opposite will trace all functions from all modules, but not from
      kernel.
      
        sh# echo '*:mod:*snd*' > set_ftrace_filter
      
      Will trace your sound drivers only (if any).
      
      Link: http://lkml.kernel.org/r/1443545176-3215-4-git-send-email-0x7f454c46@gmail.comSigned-off-by: NDmitry Safonov <0x7f454c46@gmail.com>
      [ Made format changes ]
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      0b507e1e
    • D
      ftrace: Introduce ftrace_glob structure · 3ba00929
      Dmitry Safonov 提交于
      ftrace_match parameters are very related and I reduce the number of local
      variables & parameters with it.
      This is also preparation for module globbing as it would introduce more
      realated variables & parameters.
      
      Link: http://lkml.kernel.org/r/1443545176-3215-3-git-send-email-0x7f454c46@gmail.comSigned-off-by: NDmitry Safonov <0x7f454c46@gmail.com>
      [ Made some formatting changes ]
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      3ba00929
  13. 16 10月, 2015 1 次提交
  14. 14 10月, 2015 1 次提交
  15. 06 10月, 2015 1 次提交
  16. 01 10月, 2015 2 次提交
  17. 25 7月, 2015 1 次提交
  18. 21 7月, 2015 1 次提交
  19. 03 4月, 2015 1 次提交
  20. 09 3月, 2015 3 次提交
    • S
      ftrace: Fix ftrace enable ordering of sysctl ftrace_enabled · 524a3868
      Steven Rostedt (Red Hat) 提交于
      Some archs (specifically PowerPC), are sensitive with the ordering of
      the enabling of the calls to function tracing and setting of the
      function to use to be traced.
      
      That is, update_ftrace_function() sets what function the ftrace_caller
      trampoline should call. Some archs require this to be set before
      calling ftrace_run_update_code().
      
      Another bug was discovered, that ftrace_startup_sysctl() called
      ftrace_run_update_code() directly. If the function the ftrace_caller
      trampoline changes, then it will not be updated. Instead a call
      to ftrace_startup_enable() should be called because it tests to see
      if the callback changed since the code was disabled, and will
      tell the arch to update appropriately. Most archs do not need this
      notification, but PowerPC does.
      
      The problem could be seen by the following commands:
      
       # echo 0 > /proc/sys/kernel/ftrace_enabled
       # echo function > /sys/kernel/debug/tracing/current_tracer
       # echo 1 > /proc/sys/kernel/ftrace_enabled
       # cat /sys/kernel/debug/tracing/trace
      
      The trace will show that function tracing was not active.
      
      Cc: stable@vger.kernel.org # 2.6.27+
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      524a3868
    • P
      ftrace: Fix en(dis)able graph caller when en(dis)abling record via sysctl · 1619dc3f
      Pratyush Anand 提交于
      When ftrace is enabled globally through the proc interface, we must check if
      ftrace_graph_active is set. If it is set, then we should also pass the
      FTRACE_START_FUNC_RET command to ftrace_run_update_code(). Similarly, when
      ftrace is disabled globally through the proc interface, we must check if
      ftrace_graph_active is set. If it is set, then we should also pass the
      FTRACE_STOP_FUNC_RET command to ftrace_run_update_code().
      
      Consider the following situation.
      
       # echo 0 > /proc/sys/kernel/ftrace_enabled
      
      After this ftrace_enabled = 0.
      
       # echo function_graph > /sys/kernel/debug/tracing/current_tracer
      
      Since ftrace_enabled = 0, ftrace_enable_ftrace_graph_caller() is never
      called.
      
       # echo 1 > /proc/sys/kernel/ftrace_enabled
      
      Now ftrace_enabled will be set to true, but still
      ftrace_enable_ftrace_graph_caller() will not be called, which is not
      desired.
      
      Further if we execute the following after this:
        # echo nop > /sys/kernel/debug/tracing/current_tracer
      
      Now since ftrace_enabled is set it will call
      ftrace_disable_ftrace_graph_caller(), which causes a kernel warning on
      the ARM platform.
      
      On the ARM platform, when ftrace_enable_ftrace_graph_caller() is called,
      it checks whether the old instruction is a nop or not. If it's not a nop,
      then it returns an error. If it is a nop then it replaces instruction at
      that address with a branch to ftrace_graph_caller.
      ftrace_disable_ftrace_graph_caller() behaves just the opposite. Therefore,
      if generic ftrace code ever calls either ftrace_enable_ftrace_graph_caller()
      or ftrace_disable_ftrace_graph_caller() consecutively two times in a row,
      then it will return an error, which will cause the generic ftrace code to
      raise a warning.
      
      Note, x86 does not have an issue with this because the architecture
      specific code for ftrace_enable_ftrace_graph_caller() and
      ftrace_disable_ftrace_graph_caller() does not check the previous state,
      and calling either of these functions twice in a row has no ill effect.
      
      Link: http://lkml.kernel.org/r/e4fbe64cdac0dd0e86a3bf914b0f83c0b419f146.1425666454.git.panand@redhat.com
      
      Cc: stable@vger.kernel.org # 2.6.31+
      Signed-off-by: NPratyush Anand <panand@redhat.com>
      [
        removed extra if (ftrace_start_up) and defined ftrace_graph_active as 0
        if CONFIG_FUNCTION_GRAPH_TRACER is not set.
      ]
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      1619dc3f
    • S
      ftrace: Clear REGS_EN and TRAMP_EN flags on disabling record via sysctl · b24d443b
      Steven Rostedt (Red Hat) 提交于
      When /proc/sys/kernel/ftrace_enabled is set to zero, all function
      tracing is disabled. But the records that represent the functions
      still hold information about the ftrace_ops that are hooked to them.
      
      ftrace_ops may request "REGS" (have a full set of pt_regs passed to
      the callback), or "TRAMP" (the ops has its own trampoline to use).
      When the record is updated to represent the state of the ops hooked
      to it, it sets "REGS_EN" and/or "TRAMP_EN" to state that the callback
      points to the correct trampoline (REGS has its own trampoline).
      
      When ftrace_enabled is set to zero, all ftrace locations are a nop,
      so they do not point to any trampoline. But the _EN flags are still
      set. This can cause the accounting to go wrong when ftrace_enabled
      is cleared and an ops that has a trampoline is registered or unregistered.
      
      For example, the following will cause ftrace to crash:
      
       # echo function_graph > /sys/kernel/debug/tracing/current_tracer
       # echo 0 > /proc/sys/kernel/ftrace_enabled
       # echo nop > /sys/kernel/debug/tracing/current_tracer
       # echo 1 > /proc/sys/kernel/ftrace_enabled
       # echo function_graph > /sys/kernel/debug/tracing/current_tracer
      
      As function_graph uses a trampoline, when ftrace_enabled is set to zero
      the updates to the record are not done. When enabling function_graph
      again, the record will still have the TRAMP_EN flag set, and it will
      look for an op that has a trampoline other than the function_graph
      ops, and fail to find one.
      
      Cc: stable@vger.kernel.org # 3.17+
      Reported-by: NPratyush Anand <panand@redhat.com>
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      b24d443b
  21. 04 2月, 2015 1 次提交
    • S
      tracing: Convert the tracing facility over to use tracefs · 8434dc93
      Steven Rostedt (Red Hat) 提交于
      debugfs was fine for the tracing facility as a quick way to get
      an interface. Now that tracing has matured, it should separate itself
      from debugfs such that it can be mounted separately without needing
      to mount all of debugfs with it. That is, users resist using tracing
      because it requires mounting debugfs. Having tracing have its own file
      system lets users get the features of tracing without needing to bring
      in the rest of the kernel's debug infrastructure.
      
      Another reason for tracefs is that debubfs does not support mkdir.
      Currently, to create instances, one does a mkdir in the tracing/instance
      directory. This is implemented via a hack that forces debugfs to do
      something it is not intended on doing. By converting over to tracefs, this
      hack can be removed and mkdir can be properly implemented. This patch does
      not address this yet, but it lays the ground work for that to be done.
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      8434dc93
  22. 23 1月, 2015 1 次提交
  23. 15 1月, 2015 2 次提交
  24. 22 11月, 2014 1 次提交
    • M
      ftrace, kprobes: Support IPMODIFY flag to find IP modify conflict · f8b8be8a
      Masami Hiramatsu 提交于
      Introduce FTRACE_OPS_FL_IPMODIFY to avoid conflict among
      ftrace users who may modify regs->ip to change the execution
      path. If two or more users modify the regs->ip on the same
      function entry, one of them will be broken. So they must add
      IPMODIFY flag and make sure that ftrace_set_filter_ip() succeeds.
      
      Note that ftrace doesn't allow ftrace_ops which has IPMODIFY
      flag to have notrace hash, and the ftrace_ops must have a
      filter hash (so that the ftrace_ops can hook only specific
      entries), because it strongly depends on the address and
      must be allowed for only few selected functions.
      
      Link: http://lkml.kernel.org/r/20141121102516.11844.27829.stgit@localhost.localdomain
      
      Cc: Jiri Kosina <jkosina@suse.cz>
      Cc: Seth Jennings <sjenning@redhat.com>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Vojtech Pavlik <vojtech@suse.cz>
      Cc: Miroslav Benes <mbenes@suse.cz>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      [ fixed up some of the comments ]
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      f8b8be8a
  25. 20 11月, 2014 1 次提交