1. 12 7月, 2017 6 次提交
  2. 09 7月, 2017 4 次提交
  3. 07 7月, 2017 3 次提交
  4. 06 7月, 2017 1 次提交
  5. 05 7月, 2017 2 次提交
  6. 29 6月, 2017 1 次提交
    • S
      ftrace: Fix regression with module command in stack_trace_filter · 0f179765
      Steven Rostedt (VMware) 提交于
      When doing the following command:
      
       # echo ":mod:kvm_intel" > /sys/kernel/tracing/stack_trace_filter
      
      it triggered a crash.
      
      This happened with the clean up of probes. It required all callers to the
      regex function (doing ftrace filtering) to have ops->private be a pointer to
      a trace_array. But for the stack tracer, that is not the case.
      
      Allow for the ops->private to be NULL, and change the function command
      callbacks to handle the trace_array pointer being NULL as well.
      
      Fixes: d2afd57a ("tracing/ftrace: Allow instances to have their own function probes")
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      0f179765
  7. 28 6月, 2017 6 次提交
  8. 27 6月, 2017 1 次提交
    • S
      sh/ftrace: Remove only user of ftrace_arch_read_dyn_info() · fbb789f0
      Steven Rostedt 提交于
      I noticed that there's only one user of ftrace_arch_read_dyn_info().
      That was used a while ago during the NMI updating in x86, and superh
      copied it to implement its version of handling NMIs during
      stop_machine().
      
      But that is a debug feature, and this code hasn't been touched since
      2009. Also, x86 no longer does the ftrace updates with stop_machine()
      and instead uses breakpoints. If superh needs to modify its code, it
      should implement the breakpoint conversion, and remove stop_machine().
      Which also gets rid of the NMI issue.
      
      Anyway, I want to nuke ftrace_arch_read_dyn_info() and this gets rid of
      the one user, which is for an arch that shouldn't need it anymore.
      
      Link: http://lkml.kernel.org/r/20170626181749.2ce954d1@gandalf.local.home
      
      Cc: Yoshinori Sato <ysato@users.sourceforge.jp>
      Cc: Rich Felker <dalias@libc.org>
      Cc: linux-sh@vger.kernel.org
      Signed-off-by: NSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      fbb789f0
  9. 26 6月, 2017 4 次提交
    • S
      ftrace: Have cached module filters be an active filter · 8c08f0d5
      Steven Rostedt (VMware) 提交于
      When a module filter is added to set_ftrace_filter, if the module is not
      loaded, it is cached. This should be considered an active filter, and
      function tracing should be filtered by this. That is, if a cached module
      filter is the only filter set, then no function tracing should be happening,
      as all the functions available will be filtered out.
      
      This makes sense, as the reason to add a cached module filter, is to trace
      the module when you load it. There shouldn't be any other tracing happening
      until then.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      8c08f0d5
    • S
      ftrace: Implement cached modules tracing on module load · d7fbf8df
      Steven Rostedt (VMware) 提交于
      If a module is cached in the set_ftrace_filter, and that module is loaded,
      then enable tracing on that module as if the cached module text was written
      into set_ftrace_filter just as the module is loaded.
      
        # echo ":mod:kvm_intel" >
        # cat /sys/kernel/tracing/set_ftrace_filter
       #### all functions enabled ####
       :mod:kvm_intel
        # modprobe kvm_intel
        # cat /sys/kernel/tracing/set_ftrace_filter
       vmx_get_rflags [kvm_intel]
       vmx_get_pkru [kvm_intel]
       vmx_get_interrupt_shadow [kvm_intel]
       vmx_rdtscp_supported [kvm_intel]
       vmx_invpcid_supported [kvm_intel]
       [..]
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      d7fbf8df
    • S
      ftrace: Have the cached module list show in set_ftrace_filter · 5985ea8b
      Steven Rostedt (VMware) 提交于
      When writing in a module filter into set_ftrace_filter for a module that is
      not yet loaded, it it cached, and will be executed when the module is loaded
      (although that is not implemented yet at this commit). Display the list of
      cached modules to be traced.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      5985ea8b
    • S
      ftrace: Add :mod: caching infrastructure to trace_array · 673feb9d
      Steven Rostedt (VMware) 提交于
      This is the start of the infrastructure work to allow for tracing module
      functions before it is loaded.
      
      Currently the following command:
      
        # echo :mod:some-mod > set_ftrace_filter
      
      will enable tracing of all functions within the module "some-mod" if it is
      loaded. What we want, is if the module is not loaded, that line will be
      saved. When the module is loaded, then the "some-mod" will have that line
      executed on it, so that the functions within it starts being traced.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      673feb9d
  10. 23 6月, 2017 1 次提交
    • S
      tracing: Show address when function names are not found · feaf1283
      Steven Rostedt (VMware) 提交于
      Currently, when a function is not found in kallsyms, instead of simply
      showing the function address, it shows nothing at all:
      
       # echo ':mod:kvm_intel' > /sys/kernel/tracing/set_ftrace_filter
       # echo function > /sys/kernel/tracing/set_ftrace_filter
       # qemu -enable-kvm /home/my-qemu-image
         <Ctrl-C>
       # rmmod kvm_intel
       # cat /sys/kernel/tracing/trace
       qemu-system-x86-2408  [001] d..2   135.013238:  <-kvm_arch_hardware_enable
       qemu-system-x86-2408  [001] ....   135.014574:  <-kvm_arch_vm_ioctl
       qemu-system-x86-2408  [001] ....   135.015420:  <-kvm_vm_ioctl_check_extension
       qemu-system-x86-2408  [001] ....   135.045411:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ...1   135.045413:  <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045413:  <-__do_cpuid_ent
      
      When it should show:
      
       qemu-system-x86-2408  [001] d..2   135.013238: 0xffffffffa02a39f0 <-kvm_arch_hardware_enable
       qemu-system-x86-2408  [001] ....   135.014574: 0xffffffffa02a2ba0 <-kvm_arch_vm_ioctl
       qemu-system-x86-2408  [001] ....   135.015420: 0xffffffffa029e4e0 <-kvm_vm_ioctl_check_extension
       qemu-system-x86-2408  [001] ....   135.045411: 0xffffffffa02a1380 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412: 0xffffffffa029e160 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412: 0xffffffffa029e180 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045412: 0xffffffffa029e520 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ...1   135.045413: 0xffffffffa02a13b0 <-__do_cpuid_ent
       qemu-system-x86-2408  [001] ....   135.045413: 0xffffffffa02a1380 <-__do_cpuid_ent
      
      instead.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      feaf1283
  11. 22 6月, 2017 1 次提交
  12. 14 6月, 2017 10 次提交