1. 11 4月, 2018 1 次提交
    • H
      tracing/uprobe: Add support for overlayfs · f0a2aa5a
      Howard McLauchlan 提交于
      uprobes cannot successfully attach to binaries located in a directory
      mounted with overlayfs.
      
      To verify, create directories for mounting overlayfs
      (upper,lower,work,merge), move some binary into merge/ and use readelf
      to obtain some known instruction of the binary. I used /bin/true and the
      entry instruction(0x13b0):
      
      	$ mount -t overlay overlay -o lowerdir=lower,upperdir=upper,workdir=work merge
      	$ cd /sys/kernel/debug/tracing
      	$ echo 'p:true_entry PATH_TO_MERGE/merge/true:0x13b0' > uprobe_events
      	$ echo 1 > events/uprobes/true_entry/enable
      
      This returns 'bash: echo: write error: Input/output error' and dmesg
      tells us 'event trace: Could not enable event true_entry'
      
      This change makes create_trace_uprobe() look for the real inode of a
      dentry. In the case of normal filesystems, this simplifies to just
      returning the inode. In the case of overlayfs(and similar fs) we will
      obtain the underlying dentry and corresponding inode, upon which uprobes
      can successfully register.
      
      Running the example above with the patch applied, we can see that the
      uprobe is enabled and will output to trace as expected.
      
      Link: http://lkml.kernel.org/r/20180410231030.2720-1-hmclauchlan@fb.comReviewed-by: NJosef Bacik <jbacik@fb.com>
      Reviewed-by: NMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: NSrikar Dronamraju <srikar@linux.vnet.ibm.com>
      Signed-off-by: NHoward McLauchlan <hmclauchlan@fb.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      f0a2aa5a
  2. 24 1月, 2018 1 次提交
  3. 25 10月, 2017 1 次提交
    • Y
      bpf: permit multiple bpf attachments for a single perf event · e87c6bc3
      Yonghong Song 提交于
      This patch enables multiple bpf attachments for a
      kprobe/uprobe/tracepoint single trace event.
      Each trace_event keeps a list of attached perf events.
      When an event happens, all attached bpf programs will
      be executed based on the order of attachment.
      
      A global bpf_event_mutex lock is introduced to protect
      prog_array attaching and detaching. An alternative will
      be introduce a mutex lock in every trace_event_call
      structure, but it takes a lot of extra memory.
      So a global bpf_event_mutex lock is a good compromise.
      
      The bpf prog detachment involves allocation of memory.
      If the allocation fails, a dummy do-nothing program
      will replace to-be-detached program in-place.
      Signed-off-by: NYonghong Song <yhs@fb.com>
      Acked-by: NAlexei Starovoitov <ast@kernel.org>
      Acked-by: NMartin KaFai Lau <kafai@fb.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      e87c6bc3
  4. 17 10月, 2017 1 次提交
  5. 05 10月, 2017 1 次提交
  6. 29 8月, 2017 1 次提交
    • Z
      perf/ftrace: Fix double traces of perf on ftrace:function · 75e83876
      Zhou Chengming 提交于
      When running perf on the ftrace:function tracepoint, there is a bug
      which can be reproduced by:
      
        perf record -e ftrace:function -a sleep 20 &
        perf record -e ftrace:function ls
        perf script
      
                    ls 10304 [005]   171.853235: ftrace:function:
        perf_output_begin
                    ls 10304 [005]   171.853237: ftrace:function:
        perf_output_begin
                    ls 10304 [005]   171.853239: ftrace:function:
        task_tgid_nr_ns
                    ls 10304 [005]   171.853240: ftrace:function:
        task_tgid_nr_ns
                    ls 10304 [005]   171.853242: ftrace:function:
        __task_pid_nr_ns
                    ls 10304 [005]   171.853244: ftrace:function:
        __task_pid_nr_ns
      
      We can see that all the function traces are doubled.
      
      The problem is caused by the inconsistency of the register
      function perf_ftrace_event_register() with the probe function
      perf_ftrace_function_call(). The former registers one probe
      for every perf_event. And the latter handles all perf_events
      on the current cpu. So when two perf_events on the current cpu,
      the traces of them will be doubled.
      
      So this patch adds an extra parameter "event" for perf_tp_event,
      only send sample data to this event when it's not NULL.
      Signed-off-by: NZhou Chengming <zhouchengming1@huawei.com>
      Reviewed-by: NJiri Olsa <jolsa@kernel.org>
      Acked-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: acme@kernel.org
      Cc: alexander.shishkin@linux.intel.com
      Cc: huawei.libin@huawei.com
      Link: http://lkml.kernel.org/r/1503668977-12526-1-git-send-email-zhouchengming1@huawei.comSigned-off-by: NIngo Molnar <mingo@kernel.org>
      75e83876
  7. 02 3月, 2017 1 次提交
  8. 15 2月, 2017 1 次提交
  9. 18 1月, 2017 1 次提交
    • K
      uprobe: Find last occurrence of ':' when parsing uprobe PATH:OFFSET · 6496bb72
      Kenny Yu 提交于
      Previously, `create_trace_uprobe` found the *first* occurence
      of the ':' character when parsing `PATH:OFFSET` for a uprobe.
      However, if the path contains a ':' character, then the function
      would parse the path incorrectly. Even worse, if the path does not
      exist, the subsequent call to `kern_path()` would set `ret` to
      `ENOENT`, leading to very cryptic errno values in user space.
      
      The fix is to find the *last* occurence of ':'.
      
      How to repro:: The write fails with "No such file or directory", suggesting
      incorrectly that the `uprobe_events` file does not exist.
      
        $ mkdir testing && cd testing
        $ cp /bin/bash .
        $ cp /bin/bash ./bash:with:colon
        $ echo "p:uprobes/p__root_testing_bash_0x6 /root/testing/bash:0x6" > /sys/kernel/debug/tracing/uprobe_events     # this works
        $ echo "p:uprobes/p__root_testing_bash_with_colon_0x6 /root/testing/bash:with:colon:0x6" >> /sys/kernel/debug/tracing/uprobe_events     # this doesn't
        -bash: echo: write error: No such file or directory
      
      With the patch:
      
        $ echo "p:uprobes/p__root_testing_bash_0x6 /root/testing/bash:0x6" > /sys/kernel/debug/tracing/uprobe_events     # this still works
        $ echo "p:uprobes/p__root_testing_bash_with_colon_0x6 /root/testing/bash:with:colon:0x6" >> /sys/kernel/debug/tracing/uprobe_events     # this works now too!
        $ cat /sys/kernel/debug/tracing/uprobe_events
        p:uprobes/p__root_testing_bash_0x6 /root/testing/bash:0x0000000000000006
        p:uprobes/p__root_testing_bash_with_colon_0x6 /root/testing/bash:with:colon:0x0000000000000006
      
      Link: http://lkml.kernel.org/r/20170113165834.4081016-1-kennyyu@fb.comSigned-off-by: NKenny Yu <kennyyu@fb.com>
      Reviewed-by: NOmar Sandoval <osandov@fb.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      6496bb72
  10. 01 9月, 2016 1 次提交
  11. 24 8月, 2016 1 次提交
  12. 08 4月, 2016 1 次提交
  13. 23 3月, 2016 1 次提交
  14. 26 8月, 2015 1 次提交
  15. 07 8月, 2015 1 次提交
    • W
      tracing, perf: Implement BPF programs attached to uprobes · 04a22fae
      Wang Nan 提交于
      By copying BPF related operation to uprobe processing path, this patch
      allow users attach BPF programs to uprobes like what they are already
      doing on kprobes.
      
      After this patch, users are allowed to use PERF_EVENT_IOC_SET_BPF on a
      uprobe perf event. Which make it possible to profile user space programs
      and kernel events together using BPF.
      
      Because of this patch, CONFIG_BPF_EVENTS should be selected by
      CONFIG_UPROBE_EVENT to ensure trace_call_bpf() is compiled even if
      KPROBE_EVENT is not set.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Acked-by: NAlexei Starovoitov <ast@plumgrid.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kaixu Xia <xiakaixu@huawei.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/1435716878-189507-3-git-send-email-wangnan0@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      04a22fae
  16. 14 5月, 2015 5 次提交
  17. 16 4月, 2015 1 次提交
  18. 25 3月, 2015 1 次提交
  19. 23 3月, 2015 1 次提交
  20. 23 1月, 2015 1 次提交
  21. 14 1月, 2015 1 次提交
    • P
      perf: Avoid horrible stack usage · 86038c5e
      Peter Zijlstra (Intel) 提交于
      Both Linus (most recent) and Steve (a while ago) reported that perf
      related callbacks have massive stack bloat.
      
      The problem is that software events need a pt_regs in order to
      properly report the event location and unwind stack. And because we
      could not assume one was present we allocated one on stack and filled
      it with minimal bits required for operation.
      
      Now, pt_regs is quite large, so this is undesirable. Furthermore it
      turns out that most sites actually have a pt_regs pointer available,
      making this even more onerous, as the stack space is pointless waste.
      
      This patch addresses the problem by observing that software events
      have well defined nesting semantics, therefore we can use static
      per-cpu storage instead of on-stack.
      
      Linus made the further observation that all but the scheduler callers
      of perf_sw_event() have a pt_regs available, so we change the regular
      perf_sw_event() to require a valid pt_regs (where it used to be
      optional) and add perf_sw_event_sched() for the scheduler.
      
      We have a scheduler specific call instead of a more generic _noregs()
      like construct because we can assume non-recursion from the scheduler
      and thereby simplify the code further (_noregs would have to put the
      recursion context call inline in order to assertain which __perf_regs
      element to use).
      
      One last note on the implementation of perf_trace_buf_prepare(); we
      allow .regs = NULL for those cases where we already have a pt_regs
      pointer available and do not need another.
      Reported-by: NLinus Torvalds <torvalds@linux-foundation.org>
      Reported-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
      Cc: Javi Merino <javi.merino@arm.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Petr Mladek <pmladek@suse.cz>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
      Cc: Vaibhav Nagarnaik <vnagarnaik@google.com>
      Link: http://lkml.kernel.org/r/20141216115041.GW3337@twins.programming.kicks-ass.netSigned-off-by: NIngo Molnar <mingo@kernel.org>
      86038c5e
  22. 20 11月, 2014 2 次提交
  23. 14 11月, 2014 2 次提交
  24. 17 7月, 2014 1 次提交
  25. 01 7月, 2014 3 次提交
  26. 01 5月, 2014 2 次提交
  27. 24 4月, 2014 1 次提交
  28. 17 4月, 2014 1 次提交
  29. 09 4月, 2014 1 次提交
  30. 21 2月, 2014 2 次提交