1. 20 Feb, 2014 10 commits
  2. 11 Feb, 2014 1 commit
    • Steven Rostedt (Red Hat)'s avatar
      ring-buffer: Fix first commit on sub-buffer having non-zero delta · d651aa1d
      Steven Rostedt (Red Hat) authored
      Each sub-buffer (buffer page) has a full 64 bit timestamp. The events on
      that page use a 27 bit delta against that timestamp in order to save on
      bits written to the ring buffer. If the time between events is larger than
      what the 27 bits can hold, a "time extend" event is added to hold the
      entire 64 bit timestamp again and the events after that hold a delta from
      that timestamp.
      
      As a "time extend" is always paired with an event, it is logical to just
      allocate the event with the time extend, to make things a bit more efficient.
      
      Unfortunately, when the pairing code was written, it removed the "delta = 0"
      from the first commit on a page, causing the events on the page to be
      slightly skewed.
      
      Fixes: 69d1b839
      
       "ring-buffer: Bind time extend and data events together"
      Cc: stable@vger.kernel.org # 2.6.37+
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      d651aa1d
  3. 23 Jan, 2014 3 commits
  4. 19 Jan, 2014 1 commit
    • Al Viro's avatar
      tracing: Fix buggered tee(2) on tracing_pipe · 92fdd98c
      Al Viro authored
      
      
      In kernel/trace/trace.c we have this:
      static void tracing_pipe_buf_release(struct pipe_inode_info *pipe,
                                           struct pipe_buffer *buf)
      {
              __free_page(buf->page);
      }
      static const struct pipe_buf_operations tracing_pipe_buf_ops = {
              .can_merge              = 0,
              .map                    = generic_pipe_buf_map,
              .unmap                  = generic_pipe_buf_unmap,
              .confirm                = generic_pipe_buf_confirm,
              .release                = tracing_pipe_buf_release,
              .steal                  = generic_pipe_buf_steal,
              .get                    = generic_pipe_buf_get,
      };
      with
      void generic_pipe_buf_get(struct pipe_inode_info *pipe, struct pipe_buffer *buf)
      {
              page_cache_get(buf->page);
      }
      
      and I don't see anything that would've prevented tee(2) called on the pipe
      that got stuff spliced into it from that sucker.  ->ops->get() will be
      called, then buf gets copied into target pipe's ->bufs[] and eventually
      readers get to both copies of the buffer.  With
      	get_page(page)
      	look at that page
      	__free_page(page)
      	look at that page
      	__free_page(page)
      which is not a good thing, to put it mildly.  AFAICS, that ought to use
      the normal generic_pipe_buf_release() (aka page_cache_release(buf->page)),
      shouldn't it?
      
      [
       SDR - As trace_pipe just allocates the page with alloc_page(GFP_KERNEL),
        and doesn't do anything special with it (no LRU logic). The __free_page()
        should be fine, as it wont actually free a page with reference count.
        Maybe there's a chance to leak memory? Anyway, This change is at a minimum
        good for being symmetric with generic_pipe_buf_get, it is fine to add.
      ]
      Signed-off-by: default avatarAl Viro <viro@zeniv.linux.org.uk>
      [ SDR - Removed no longer used tracing_pipe_buf_release ]
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      92fdd98c
  5. 14 Jan, 2014 1 commit
    • Steven Rostedt (Red Hat)'s avatar
      tracing: Have trace buffer point back to trace_array · dced341b
      Steven Rostedt (Red Hat) authored
      The trace buffer has a descriptor pointer that goes back to the trace
      array. But it was never assigned. Luckily, nothing uses it (yet), but
      it will in the future.
      
      Although nothing currently uses this, if any of the new features get
      backported to older kernels, and because this is such a simple change,
      I'm marking it for stable too.
      
      Cc: stable@vger.kernel.org # v3.10+
      Fixes: 12883efb
      
       "tracing: Consolidate max_tr into main trace_array structure"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      dced341b
  6. 13 Jan, 2014 5 commits
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Fix synchronization location disabling and freeing ftrace_ops · a4c35ed2
      Steven Rostedt (Red Hat) authored
      The synchronization needed after ftrace_ops are unregistered must happen
      after the callback is disabled from becing called by functions.
      
      The current location happens after the function is being removed from the
      internal lists, but not after the function callbacks were disabled, leaving
      the functions susceptible of being called after their callbacks are freed.
      
      This affects perf and any externel users of function tracing (LTTng and
      SystemTap).
      
      Cc: stable@vger.kernel.org # 3.0+
      Fixes: cdbe61bf
      
       "ftrace: Allow dynamically allocated function tracers"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      a4c35ed2
    • Steven Rostedt (Red Hat)'s avatar
      ftrace: Have function graph only trace based on global_ops filters · 23a8e844
      Steven Rostedt (Red Hat) authored
      Doing some different tests, I discovered that function graph tracing, when
      filtered via the set_ftrace_filter and set_ftrace_notrace files, does
      not always keep with them if another function ftrace_ops is registered
      to trace functions.
      
      The reason is that function graph just happens to trace all functions
      that the function tracer enables. When there was only one user of
      function tracing, the function graph tracer did not need to worry about
      being called by functions that it did not want to trace. But now that there
      are other users, this becomes a problem.
      
      For example, one just needs to do the following:
      
       # cd /sys/kernel/debug/tracing
       # echo schedule > set_ftrace_filter
       # echo function_graph > current_tracer
       # cat trace
      [..]
       0)               |  schedule() {
       ------------------------------------------
       0)    <idle>-0    =>   rcu_pre-7
       ------------------------------------------
      
       0) ! 2980.314 us |  }
       0)               |  schedule() {
       ------------------------------------------
       0)   rcu_pre-7    =>    <idle>-0
       ------------------------------------------
      
       0) + 20.701 us   |  }
      
       # echo 1 > /proc/sys/kernel/stack_tracer_enabled
       # cat trace
      [..]
       1) + 20.825 us   |      }
       1) + 21.651 us   |    }
       1) + 30.924 us   |  } /* SyS_ioctl */
       1)               |  do_page_fault() {
       1)               |    __do_page_fault() {
       1)   0.274 us    |      down_read_trylock();
       1)   0.098 us    |      find_vma();
       1)               |      handle_mm_fault() {
       1)               |        _raw_spin_lock() {
       1)   0.102 us    |          preempt_count_add();
       1)   0.097 us    |          do_raw_spin_lock();
       1)   2.173 us    |        }
       1)               |        do_wp_page() {
       1)   0.079 us    |          vm_normal_page();
       1)   0.086 us    |          reuse_swap_page();
       1)   0.076 us    |          page_move_anon_rmap();
       1)               |          unlock_page() {
       1)   0.082 us    |            page_waitqueue();
       1)   0.086 us    |            __wake_up_bit();
       1)   1.801 us    |          }
       1)   0.075 us    |          ptep_set_access_flags();
       1)               |          _raw_spin_unlock() {
       1)   0.098 us    |            do_raw_spin_unlock();
       1)   0.105 us    |            preempt_count_sub();
       1)   1.884 us    |          }
       1)   9.149 us    |        }
       1) + 13.083 us   |      }
       1)   0.146 us    |      up_read();
      
      When the stack tracer was enabled, it enabled all functions to be traced, which
      now the function graph tracer also traces. This is a side effect that should
      not occur.
      
      To fix this a test is added when the function tracing is changed, as well as when
      the graph tracer is enabled, to see if anything other than the ftrace global_ops
      function tracer is enabled. If so, then the graph tracer calls a test trampoline
      that will look at the function that is being traced and compare it with the
      filters defined by the global_ops.
      
      As an optimization, if there's no other function tracers registered, or if
      the only registered function tracers also use the global ops, the function
      graph infrastructure will call the registered function graph callback directly
      and not go through the test trampoline.
      
      Cc: stable@vger.kernel.org # 3.3+
      Fixes: d2d45c7a
      
       "tracing: Have stack_tracer use a separate list of functions"
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      23a8e844
    • Peter Zijlstra's avatar
      sched/clock, x86: Use a static_key for sched_clock_stable · 35af99e6
      Peter Zijlstra authored
      
      
      In order to avoid the runtime condition and variable load turn
      sched_clock_stable into a static_key.
      
      Also provide a shorter implementation of local_clock() and
      cpu_clock(int) when sched_clock_stable==1.
      
                              MAINLINE   PRE       POST
      
          sched_clock_stable: 1          1         1
          (cold) sched_clock: 329841     221876    215295
          (cold) local_clock: 301773     234692    220773
          (warm) sched_clock: 38375      25602     25659
          (warm) local_clock: 100371     33265     27242
          (warm) rdtsc:       27340      24214     24208
          sched_clock_stable: 0          0         0
          (cold) sched_clock: 382634     235941    237019
          (cold) local_clock: 396890     297017    294819
          (warm) sched_clock: 38194      25233     25609
          (warm) local_clock: 143452     71234     71232
          (warm) rdtsc:       27345      24245     24243
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Link: http://lkml.kernel.org/n/tip-eummbdechzz37mwmpags1gjr@git.kernel.org
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      35af99e6
    • Dario Faggioli's avatar
      sched/deadline: Add SCHED_DEADLINE inheritance logic · 2d3d891d
      Dario Faggioli authored
      
      
      Some method to deal with rt-mutexes and make sched_dl interact with
      the current PI-coded is needed, raising all but trivial issues, that
      needs (according to us) to be solved with some restructuring of
      the pi-code (i.e., going toward a proxy execution-ish implementation).
      
      This is under development, in the meanwhile, as a temporary solution,
      what this commits does is:
      
       - ensure a pi-lock owner with waiters is never throttled down. Instead,
         when it runs out of runtime, it immediately gets replenished and it's
         deadline is postponed;
      
       - the scheduling parameters (relative deadline and default runtime)
         used for that replenishments --during the whole period it holds the
         pi-lock-- are the ones of the waiting task with earliest deadline.
      
      Acting this way, we provide some kind of boosting to the lock-owner,
      still by using the existing (actually, slightly modified by the previous
      commit) pi-architecture.
      
      We would stress the fact that this is only a surely needed, all but
      clean solution to the problem. In the end it's only a way to re-start
      discussion within the community. So, as always, comments, ideas, rants,
      etc.. are welcome! :-)
      Signed-off-by: default avatarDario Faggioli <raistlin@linux.it>
      Signed-off-by: default avatarJuri Lelli <juri.lelli@gmail.com>
      [ Added !RT_MUTEXES build fix. ]
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1383831828-15501-11-git-send-email-juri.lelli@gmail.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      2d3d891d
    • Dario Faggioli's avatar
      sched/deadline: Add latency tracing for SCHED_DEADLINE tasks · af6ace76
      Dario Faggioli authored
      
      
      It is very likely that systems that wants/needs to use the new
      SCHED_DEADLINE policy also want to have the scheduling latency of
      the -deadline tasks under control.
      
      For this reason a new version of the scheduling wakeup latency,
      called "wakeup_dl", is introduced.
      
      As a consequence of applying this patch there will be three wakeup
      latency tracer:
      
       * "wakeup", that deals with all tasks in the system;
       * "wakeup_rt", that deals with -rt and -deadline tasks only;
       * "wakeup_dl", that deals with -deadline tasks only.
      Signed-off-by: default avatarDario Faggioli <raistlin@linux.it>
      Signed-off-by: default avatarJuri Lelli <juri.lelli@gmail.com>
      Signed-off-by: default avatarPeter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1383831828-15501-9-git-send-email-juri.lelli@gmail.com
      
      Signed-off-by: default avatarIngo Molnar <mingo@kernel.org>
      af6ace76
  7. 10 Jan, 2014 4 commits
  8. 06 Jan, 2014 2 commits
  9. 03 Jan, 2014 3 commits
    • Namhyung Kim's avatar
      tracing/probes: Fix build break on !CONFIG_KPROBE_EVENT · e0d18fe0
      Namhyung Kim authored
      
      
      When kprobe-based dynamic event tracer is not enabled, it caused
      following build error:
      
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c8dd): undefined reference to `fetch_symbol_u8'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c8e9): undefined reference to `fetch_symbol_u16'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c8f5): undefined reference to `fetch_symbol_u32'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c901): undefined reference to `fetch_symbol_u64'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c909): undefined reference to `fetch_symbol_string'
         kernel/built-in.o: In function `traceprobe_update_arg':
         (.text+0x10c913): undefined reference to `fetch_symbol_string_size'
         ...
      
      It was due to the fetch methods are referred from CHECK_FETCH_FUNCS
      macro and since it was only defined in trace_kprobe.c.  Move NULL
      definition of such fetch functions to the header file.
      
      Note, it also requires CONFIG_BRANCH_PROFILING enabled to trigger
      this failure as well. This is because the "fetch_symbol_*" variables
      are referenced in a "else if" statement that will only call
      update_symbol_cache(), which is a static inline stub function
      when CONFIG_KPROBE_EVENT is not enabled. gcc is smart enough
      to optimize this "else if" out and that also removes the code that
      references the undefined variables.
      
      But when BRANCH_PROFILING is enabled, it fools gcc into keeping
      the if statement around and thus references the undefined symbols
      and fails to build.
      Reported-by: default avatarkbuild test robot <fengguang.wu@intel.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      e0d18fe0
    • Namhyung Kim's avatar
      tracing/uprobes: Add @+file_offset fetch method · b7e0bf34
      Namhyung Kim authored
      
      
      Enable to fetch data from a file offset.  Currently it only supports
      fetching from same binary uprobe set.  It'll translate the file offset
      to a proper virtual address in the process.
      
      The syntax is "@+OFFSET" as it does similar to normal memory fetching
      (@ADDR) which does no address translation.
      Suggested-by: default avatarOleg Nesterov <oleg@redhat.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      b7e0bf34
    • Namhyung Kim's avatar
      tracing/uprobes: Add support for full argument access methods · b079d374
      Namhyung Kim authored
      
      
      Enable to fetch other types of argument for the uprobes.  IOW, we can
      access stack, memory, deref, bitfield and retval from uprobes now.
      
      The format for the argument types are same as kprobes (but @SYMBOL
      type is not supported for uprobes), i.e:
      
        @ADDR   : Fetch memory at ADDR
        $stackN : Fetch Nth entry of stack (N >= 0)
        $stack  : Fetch stack address
        $retval : Fetch return value
        +|-offs(FETCHARG) : Fetch memory at FETCHARG +|- offs address
      
      Note that the retval only can be used with uretprobes.
      Original-patch-by: default avatarHyeoncheol Lee <cheol.lee@lge.com>
      Acked-by: default avatarMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: zhangwei(Jovi) <jovi.zhangwei@huawei.com>
      Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: default avatarHyeoncheol Lee <cheol.lee@lge.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      b079d374
  10. 02 Jan, 2014 10 commits