1. 14 Mar, 2019 2 commits
  2. 13 Mar, 2019 1 commit
    • Douglas Anderson's avatar
      tracing: kdb: Fix ftdump to not sleep · 31b265b3
      Douglas Anderson authored
      As reported back in 2016-11 [1], the "ftdump" kdb command triggers a
      BUG for "sleeping function called from invalid context".
      
      kdb's "ftdump" command wants to call ring_buffer_read_prepare() in
      atomic context.  A very simple solution for this is to add allocation
      flags to ring_buffer_read_prepare() so kdb can call it without
      triggering the allocation error.  This patch does that.
      
      Note that in the original email thread about this, it was suggested
      that perhaps the solution for kdb was to either preallocate the buffer
      ahead of time or create our own iterator.  I'm hoping that this
      alternative of adding allocation flags to ring_buffer_read_prepare()
      can be considered since it means I don't need to duplicate more of the
      core trace code into "trace_kdb.c" (for either creating my own
      iterator or re-preparing a ring allocator whose memory was already
      allocated).
      
      NOTE: another option for kdb is to actually figure out how to make it
      reuse the existing ftrace_dump() function and totally eliminate the
      duplication.  This sounds very appealing and actually works (the "sr
      z" command can be seen to properly dump the ftrace buffer).  The
      downside here is that ftrace_dump() fully consumes the trace buffer.
      Unless that is changed I'd rather not use it because it means "ftdump
      | grep xyz" won't be very useful to search the ftrace buffer since it
      will throw away the whole trace on the first grep.  A future patch to
      dump only the last few lines of the buffer will also be hard to
      implement.
      
      [1] https://lkml.kernel.org/r/20161117191605.GA21459@google.com
      
      Link: http://lkml.kernel.org/r/20190308193205.213659-1-dianders@chromium.orgReported-by: default avatarBrian Norris <briannorris@chromium.org>
      Signed-off-by: default avatarDouglas Anderson <dianders@chromium.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      31b265b3
  3. 12 Mar, 2019 2 commits
  4. 05 Mar, 2019 5 commits
  5. 21 Feb, 2019 2 commits
  6. 20 Feb, 2019 18 commits
  7. 15 Feb, 2019 2 commits
    • Elena Reshetova's avatar
      uprobes: convert uprobe.ref to refcount_t · ce59b8e9
      Elena Reshetova authored
      atomic_t variables are currently used to implement reference
      counters with the following properties:
       - counter is initialized to 1 using atomic_set()
       - a resource is freed upon counter reaching zero
       - once counter reaches zero, its further
         increments aren't allowed
       - counter schema uses basic atomic operations
         (set, inc, inc_not_zero, dec_and_test, etc.)
      
      Such atomic variables should be converted to a newly provided
      refcount_t type and API that prevents accidental counter overflows
      and underflows. This is important since overflows and underflows
      can lead to use-after-free situation and be exploitable.
      
      The variable uprobe.ref is used as pure reference counter.
      Convert it to refcount_t and fix up the operations.
      
      **Important note for maintainers:
      
      Some functions from refcount_t API defined in lib/refcount.c
      have different memory ordering guarantees than their atomic
      counterparts.
      The full comparison can be seen in
      https://lkml.org/lkml/2017/11/15/57 and it is hopefully soon
      in state to be merged to the documentation tree.
      Normally the differences should not matter since refcount_t provides
      enough guarantees to satisfy the refcounting use cases, but in
      some rare cases it might matter.
      Please double check that you don't have some undocumented
      memory guarantees for this variable usage.
      
      For the uprobe.ref it might make a difference
      in following places:
       - put_uprobe(): decrement in refcount_dec_and_test() only
         provides RELEASE ordering and control dependency on success
         vs. fully ordered atomic counterpart
      
      Link: http://lkml.kernel.org/r/1547637627-29526-1-git-send-email-elena.reshetova@intel.comSuggested-by: default avatarKees Cook <keescook@chromium.org>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Reviewed-by: default avatarDavid Windsor <dwindsor@gmail.com>
      Reviewed-by: default avatarHans Liljestrand <ishkamiel@gmail.com>
      Reviewed-by: default avatarSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: default avatarElena Reshetova <elena.reshetova@intel.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      ce59b8e9
    • Steven Rostedt (VMware)'s avatar
      ftrace: Allow enabling of filters via index of available_filter_functions · f79b3f33
      Steven Rostedt (VMware) authored
      Enabling of large number of functions by echoing in a large subset of the
      functions in available_filter_functions can take a very long time. The
      process requires testing all functions registered by the function tracer
      (which is in the 10s of thousands), and doing a kallsyms lookup to convert
      the ip address into a name, then comparing that name with the string passed
      in.
      
      When a function causes the function tracer to crash the system, a binary
      bisect of the available_filter_functions can be done to find the culprit.
      But this requires passing in half of the functions in
      available_filter_functions over and over again, which makes it basically a
      O(n^2) operation. With 40,000 functions, that ends up bing 1,600,000,000
      opertions! And enabling this can take over 20 minutes.
      
      As a quick speed up, if a number is passed into one of the filter files,
      instead of doing a search, it just enables the function at the corresponding
      line of the available_filter_functions file. That is:
      
       # echo 50 > set_ftrace_filter
       # cat set_ftrace_filter
       x86_pmu_commit_txn
      
       # head -50 available_filter_functions | tail -1
       x86_pmu_commit_txn
      
      This allows setting of half the available_filter_functions to take place in
      less than a second!
      
       # time seq 20000 > set_ftrace_filter
       real    0m0.042s
       user    0m0.005s
       sys     0m0.015s
      
       # wc -l set_ftrace_filter
       20000 set_ftrace_filter
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      f79b3f33
  8. 11 Feb, 2019 1 commit
    • Changbin Du's avatar
      tracing: Change the function format to display function names by perf · 85acbb21
      Changbin Du authored
      Here is an example for this change.
      
      $ sudo perf record -e 'ftrace:function' --filter='ip==schedule'
      $ sudo perf report
      
      The output of perf before this patch:
      
      \# Samples: 100  of event 'ftrace:function'
      \# Event count (approx.): 100
      \#
      \# Overhead  Trace output
      \# ........  ......................................
      \#
          51.00%   ffffffff81f6aaa0 <-- ffffffff81158e8d
          29.00%   ffffffff81f6aaa0 <-- ffffffff8116ccb2
           8.00%   ffffffff81f6aaa0 <-- ffffffff81f6f2ed
           4.00%   ffffffff81f6aaa0 <-- ffffffff811628db
           4.00%   ffffffff81f6aaa0 <-- ffffffff81f6ec5b
           2.00%   ffffffff81f6aaa0 <-- ffffffff81f6f21a
           1.00%   ffffffff81f6aaa0 <-- ffffffff811b04af
           1.00%   ffffffff81f6aaa0 <-- ffffffff8143ce17
      
      After this patch:
      
      \# Samples: 36  of event 'ftrace:function'
      \# Event count (approx.): 36
      \#
      \# Overhead  Trace output
      \# ........  ............................................
      \#
          38.89%   schedule <-- schedule_hrtimeout_range_clock
          27.78%   schedule <-- worker_thread
          13.89%   schedule <-- schedule_timeout
          11.11%   schedule <-- smpboot_thread_fn
           5.56%   schedule <-- rcu_gp_kthread
           2.78%   schedule <-- exit_to_usermode_loop
      
      Link: http://lkml.kernel.org/r/20190209161919.32350-1-changbin.du@gmail.comSigned-off-by: default avatarChangbin Du <changbin.du@gmail.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      85acbb21
  9. 06 Feb, 2019 7 commits