1. 15 Nov, 2019 1 commit
  2. 14 Nov, 2019 11 commits
  3. 13 Nov, 2019 17 commits
    • Divya Indi's avatar
      tracing: Adding NULL checks for trace_array descriptor pointer · 953ae45a
      Divya Indi authored
      As part of commit f45d1225 ("tracing: Kernel access to Ftrace
      instances") we exported certain functions. Here, we are adding some additional
      NULL checks to ensure safe usage by users of these APIs.
      
      Link: http://lkml.kernel.org/r/1565805327-579-4-git-send-email-divya.indi@oracle.comSigned-off-by: default avatarDivya Indi <divya.indi@oracle.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      953ae45a
    • Divya Indi's avatar
      tracing: Verify if trace array exists before destroying it. · e585e646
      Divya Indi authored
      A trace array can be destroyed from userspace or kernel. Verify if the
      trace array exists before proceeding to destroy/remove it.
      
      Link: http://lkml.kernel.org/r/1565805327-579-3-git-send-email-divya.indi@oracle.comReviewed-by: default avatarAruna Ramakrishna <aruna.ramakrishna@oracle.com>
      Signed-off-by: default avatarDivya Indi <divya.indi@oracle.com>
      [ Removed unneeded braces ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      e585e646
    • Divya Indi's avatar
      tracing: Declare newly exported APIs in include/linux/trace.h · 2d6425af
      Divya Indi authored
      Declare the newly introduced and exported APIs in the header file -
      include/linux/trace.h. Moving previous declarations from
      kernel/trace/trace.h to include/linux/trace.h.
      
      Link: http://lkml.kernel.org/r/1565805327-579-2-git-send-email-divya.indi@oracle.comSigned-off-by: default avatarDivya Indi <divya.indi@oracle.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      2d6425af
    • Ben Dooks's avatar
      tracing: Make internal ftrace events static · 6dff4d7d
      Ben Dooks authored
      The event_class_ftrace_##call and event_##call do not seem
      to be used outside of trace_export.c so make them both static
      to avoid a number of sparse warnings:
      
      kernel/trace/trace_entries.h:59:1: warning: symbol 'event_class_ftrace_function' was not declared. Should it be static?
      kernel/trace/trace_entries.h:59:1: warning: symbol '__event_function' was not declared. Should it be static?
      kernel/trace/trace_entries.h:77:1: warning: symbol 'event_class_ftrace_funcgraph_entry' was not declared. Should it be static?
      kernel/trace/trace_entries.h:77:1: warning: symbol '__event_funcgraph_entry' was not declared. Should it be static?
      kernel/trace/trace_entries.h:93:1: warning: symbol 'event_class_ftrace_funcgraph_exit' was not declared. Should it be static?
      kernel/trace/trace_entries.h:93:1: warning: symbol '__event_funcgraph_exit' was not declared. Should it be static?
      kernel/trace/trace_entries.h:129:1: warning: symbol 'event_class_ftrace_context_switch' was not declared. Should it be static?
      kernel/trace/trace_entries.h:129:1: warning: symbol '__event_context_switch' was not declared. Should it be static?
      kernel/trace/trace_entries.h:149:1: warning: symbol 'event_class_ftrace_wakeup' was not declared. Should it be static?
      kernel/trace/trace_entries.h:149:1: warning: symbol '__event_wakeup' was not declared. Should it be static?
      kernel/trace/trace_entries.h:171:1: warning: symbol 'event_class_ftrace_kernel_stack' was not declared. Should it be static?
      kernel/trace/trace_entries.h:171:1: warning: symbol '__event_kernel_stack' was not declared. Should it be static?
      kernel/trace/trace_entries.h:191:1: warning: symbol 'event_class_ftrace_user_stack' was not declared. Should it be static?
      kernel/trace/trace_entries.h:191:1: warning: symbol '__event_user_stack' was not declared. Should it be static?
      kernel/trace/trace_entries.h:214:1: warning: symbol 'event_class_ftrace_bprint' was not declared. Should it be static?
      kernel/trace/trace_entries.h:214:1: warning: symbol '__event_bprint' was not declared. Should it be static?
      kernel/trace/trace_entries.h:230:1: warning: symbol 'event_class_ftrace_print' was not declared. Should it be static?
      kernel/trace/trace_entries.h:230:1: warning: symbol '__event_print' was not declared. Should it be static?
      kernel/trace/trace_entries.h:247:1: warning: symbol 'event_class_ftrace_raw_data' was not declared. Should it be static?
      kernel/trace/trace_entries.h:247:1: warning: symbol '__event_raw_data' was not declared. Should it be static?
      kernel/trace/trace_entries.h:262:1: warning: symbol 'event_class_ftrace_bputs' was not declared. Should it be static?
      kernel/trace/trace_entries.h:262:1: warning: symbol '__event_bputs' was not declared. Should it be static?
      kernel/trace/trace_entries.h:277:1: warning: symbol 'event_class_ftrace_mmiotrace_rw' was not declared. Should it be static?
      kernel/trace/trace_entries.h:277:1: warning: symbol '__event_mmiotrace_rw' was not declared. Should it be static?
      kernel/trace/trace_entries.h:298:1: warning: symbol 'event_class_ftrace_mmiotrace_map' was not declared. Should it be static?
      kernel/trace/trace_entries.h:298:1: warning: symbol '__event_mmiotrace_map' was not declared. Should it be static?
      kernel/trace/trace_entries.h:322:1: warning: symbol 'event_class_ftrace_branch' was not declared. Should it be static?
      kernel/trace/trace_entries.h:322:1: warning: symbol '__event_branch' was not declared. Should it be static?
      kernel/trace/trace_entries.h:343:1: warning: symbol 'event_class_ftrace_hwlat' was not declared. Should it be static?
      kernel/trace/trace_entries.h:343:1: warning: symbol '__event_hwlat' was not declared. Should it be static?
      
      Link: http://lkml.kernel.org/r/20191015121012.18824-1-ben.dooks@codethink.co.ukSigned-off-by: default avatarBen Dooks <ben.dooks@codethink.co.uk>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      6dff4d7d
    • Sebastian Andrzej Siewior's avatar
      tracing: Use CONFIG_PREEMPTION · 9c34fc4b
      Sebastian Andrzej Siewior authored
      CONFIG_PREEMPTION is selected by CONFIG_PREEMPT and by CONFIG_PREEMPT_RT.
      Both PREEMPT and PREEMPT_RT require the same functionality which today
      depends on CONFIG_PREEMPT.
      
      Add additional header output for PREEMPT_RT.
      Link: http://lkml.kernel.org/r/20191015191821.11479-34-bigeasy@linutronix.de
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Signed-off-by: default avatarSebastian Andrzej Siewior <bigeasy@linutronix.de>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      9c34fc4b
    • Viktor Rosendahl (BMW)'s avatar
      preemptirq_delay_test: Add the burst feature and a sysfs trigger · 79393723
      Viktor Rosendahl (BMW) authored
      This burst feature enables the user to generate a burst of
      preempt/irqsoff latencies. This makes it possible to test whether we
      are able to detect latencies that systematically occur very close to
      each other.
      
      The maximum burst size is 10. We also create 10 identical test
      functions, so that we get 10 different backtraces; this is useful
      when we want to test whether we can detect all the latencies in a
      burst. Otherwise, there would be no easy way of differentiating
      between which latency in a burst was captured by the tracer.
      
      In addition, there is a sysfs trigger, so that it's not necessary to
      reload the module to repeat the test. The trigger will appear as
      /sys/kernel/preemptirq_delay_test/trigger in sysfs.
      
      Link: http://lkml.kernel.org/r/20191008220824.7911-3-viktor.rosendahl@gmail.comReviewed-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarViktor Rosendahl (BMW) <viktor.rosendahl@gmail.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      79393723
    • Viktor Rosendahl (BMW)'s avatar
      ftrace: Implement fs notification for tracing_max_latency · 91edde2e
      Viktor Rosendahl (BMW) authored
      This patch implements the feature that the tracing_max_latency file,
      e.g. /sys/kernel/debug/tracing/tracing_max_latency will receive
      notifications through the fsnotify framework when a new latency is
      available.
      
      One particularly interesting use of this facility is when enabling
      threshold tracing, through /sys/kernel/debug/tracing/tracing_thresh,
      together with the preempt/irqsoff tracers. This makes it possible to
      implement a user space program that can, with equal probability,
      obtain traces of latencies that occur immediately after each other in
      spite of the fact that the preempt/irqsoff tracers operate in overwrite
      mode.
      
      This facility works with the hwlat, preempt/irqsoff, and wakeup
      tracers.
      
      The tracers may call the latency_fsnotify() from places such as
      __schedule() or do_idle(); this makes it impossible to call
      queue_work() directly without risking a deadlock. The same would
      happen with a softirq,  kernel thread or tasklet. For this reason we
      use the irq_work mechanism to call queue_work().
      
      This patch creates a new workqueue. The reason for doing this is that
      I wanted to use the WQ_UNBOUND and WQ_HIGHPRI flags.  My thinking was
      that WQ_UNBOUND might help with the latency in some important cases.
      
      If we use:
      
      queue_work(system_highpri_wq, &tr->fsnotify_work);
      
      then the work will (almost) always execute on the same CPU but if we are
      unlucky that CPU could be too busy while there could be another CPU in
      the system that would be able to process the work soon enough.
      
      queue_work_on() could be used to queue the work on another CPU but it
      seems difficult to select the right CPU.
      
      Link: http://lkml.kernel.org/r/20191008220824.7911-2-viktor.rosendahl@gmail.comReviewed-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarViktor Rosendahl (BMW) <viktor.rosendahl@gmail.com>
      [ Added max() to have one compare for max latency ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      91edde2e
    • Steven Rostedt (VMware)'s avatar
      ftrace: Add information on number of page groups allocated · da537f0a
      Steven Rostedt (VMware) authored
      Looking for ways to shrink the size of the dyn_ftrace structure, knowing the
      information about how many pages and the number of groups of those pages, is
      useful in working out the best ways to save on memory.
      
      This adds one info print on how many groups of pages were used to allocate
      the ftrace dyn_ftrace structures, and also shows the number of pages and
      groups in the dyn_ftrace_total_info (which is used for debugging).
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      da537f0a
    • Josh Poimboeuf's avatar
      ftrace/x86: Tell objtool to ignore nondeterministic ftrace stack layout · 77ac117b
      Josh Poimboeuf authored
      Objtool complains about the new ftrace direct trampoline code:
      
        arch/x86/kernel/ftrace_64.o: warning: objtool: ftrace_regs_caller()+0x190: stack state mismatch: cfa1=7+16 cfa2=7+24
      
      Typically, code has a deterministic stack layout, such that at a given
      instruction address, the stack frame size is always the same.
      
      That's not the case for the new ftrace_regs_caller() code after it
      adjusts the stack for the direct case.  Just plead ignorance and assume
      it's always the non-direct path.  Note this creates a tiny window for
      ORC to get confused.
      
      Link: http://lkml.kernel.org/r/20191108225100.ea3bhsbdf6oerj6g@trebleReported-by: default avatarSteven Rostedt <rostedt@goodmis.org>
      Signed-off-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      77ac117b
    • Steven Rostedt (VMware)'s avatar
      ftrace/x86: Add a counter to test function_graph with direct · a3ad1a7e
      Steven Rostedt (VMware) authored
      As testing for direct calls from the function graph tracer adds a little
      overhead (which is a lot when tracing every function), add a counter that
      can be used to test if function_graph tracer needs to test for a direct
      caller or not.
      
      It would have been nicer if we could use a static branch, but the static
      branch logic fails when used within the function graph tracer trampoline.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      a3ad1a7e
    • Steven Rostedt (VMware)'s avatar
      ftrace/x86: Add register_ftrace_direct() for custom trampolines · 562955fe
      Steven Rostedt (VMware) authored
      Enable x86 to allow for register_ftrace_direct(), where a custom trampoline
      may be called directly from an ftrace mcount/fentry location.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      562955fe
    • Steven Rostedt (VMware)'s avatar
      ftrace/selftests: Update the direct call selftests to test two direct calls · ed9dafeb
      Steven Rostedt (VMware) authored
      The register_ftrace_direct() takes a different path if there's already a
      direct call registered, but this was not tested in the self tests. Now that
      there's a second direct caller test module, we can use this to test not only
      one direct caller, but two.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      ed9dafeb
    • Steven Rostedt (VMware)'s avatar
      ftrace: Add another example of register_ftrace_direct() use case · 156473a0
      Steven Rostedt (VMware) authored
      Add another module sample that registers a direct trampoline to a function
      via register_ftrace_direct(). Having another module that does this allows to
      test the use case of multiple direct callers registered, as more than one
      direct caller goes into another path, and is needed to perform proper
      testing of the register_ftrace_direct() call.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      156473a0
    • Steven Rostedt (VMware)'s avatar
      ftrace/selftest: Add tests to test register_ftrace_direct() · 646f01cc
      Steven Rostedt (VMware) authored
      Add two test cases that test the new ftrace direct functionality if the
      ftrace-direct sample module is available. One test case tests against each
      available tracer (function, function_graph, mmiotrace, etc), and the other
      test tests against a kprobe at the same location as the direct caller. Both
      tests follow the same pattern of testing combinations:
      
        enable test (either the tracer or the kprobe)
        load direct function module
        unload direct function module
        disable test
      
        enable test
        load direct function module
        disable test
        unload direct function module
      
        load direct function module
        enable test
        disable test
        unload direct function module
      
        load direct function module
        enable test
        unload direct function module
        disable test
      
      As most the bugs in development happened with various ways of enabling or
      disabling the direct calls with function tracer in one of these
      combinations.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      646f01cc
    • Steven Rostedt (VMware)'s avatar
      ftrace: Add sample module that uses register_ftrace_direct() · b06457c8
      Steven Rostedt (VMware) authored
      Add a sample module that shows a simple use case for
      regsiter_ftrace_direct(), and how to use it.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      b06457c8
    • Steven Rostedt (VMware)'s avatar
      ftrace: Add ftrace_find_direct_func() · 013bf0da
      Steven Rostedt (VMware) authored
      As function_graph tracer modifies the return address to insert a trampoline
      to trace the return of a function, it must be aware of a direct caller, as
      when it gets called, the function's return address may not be at on the
      stack where it expects. It may have to see if that return address points to
      the a direct caller and adjust if it is.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      013bf0da
    • Steven Rostedt (VMware)'s avatar
      ftrace: Add register_ftrace_direct() · 763e34e7
      Steven Rostedt (VMware) authored
      Add the start of the functionality to allow other trampolines to use the
      ftrace mcount/fentry/nop location. This adds two new functions:
      
       register_ftrace_direct() and unregister_ftrace_direct()
      
      Both take two parameters: the first is the instruction address of where the
      mcount/fentry/nop exists, and the second is the trampoline to have that
      location called.
      
      This will handle cases where ftrace is already used on that same location,
      and will make it still work, where the registered direct called trampoline
      will get called after all the registered ftrace callers are handled.
      
      Currently, it will not allow for IP_MODIFY functions to be called at the
      same locations, which include some kprobes and live kernel patching.
      
      At this point, no architecture supports this. This is only the start of
      implementing the framework.
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      763e34e7
  4. 08 Nov, 2019 2 commits
  5. 04 Nov, 2019 3 commits
  6. 03 Nov, 2019 2 commits
    • Linus Torvalds's avatar
      Linux 5.4-rc6 · a99d8080
      Linus Torvalds authored
      a99d8080
    • Linus Torvalds's avatar
      Merge tag 'usb-5.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb · 3a69c9e5
      Linus Torvalds authored
      Pull USB fixes from Greg KH:
       "The USB sub-maintainers woke up this past week and sent a bunch of
        tiny fixes. Here are a lot of small patches that that resolve a bunch
        of reported issues in the USB core, drivers, serial drivers, gadget
        drivers, and of course, xhci :)
      
        All of these have been in linux-next with no reported issues"
      
      * tag 'usb-5.4-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb: (31 commits)
        usb: dwc3: gadget: fix race when disabling ep with cancelled xfers
        usb: cdns3: gadget: Fix g_audio use case when connected to Super-Speed host
        usb: cdns3: gadget: reset EP_CLAIMED flag while unloading
        USB: serial: whiteheat: fix line-speed endianness
        USB: serial: whiteheat: fix potential slab corruption
        USB: gadget: Reject endpoints with 0 maxpacket value
        UAS: Revert commit 3ae62a42 ("UAS: fix alignment of scatter/gather segments")
        usb-storage: Revert commit 747668db ("usb-storage: Set virt_boundary_mask to avoid SG overflows")
        usbip: Fix free of unallocated memory in vhci tx
        usbip: tools: Fix read_usb_vudc_device() error path handling
        usb: xhci: fix __le32/__le64 accessors in debugfs code
        usb: xhci: fix Immediate Data Transfer endianness
        xhci: Fix use-after-free regression in xhci clear hub TT implementation
        USB: ldusb: fix control-message timeout
        USB: ldusb: use unsigned size format specifiers
        USB: ldusb: fix ring-buffer locking
        USB: Skip endpoints with 0 maxpacket length
        usb: cdns3: gadget: Don't manage pullups
        usb: dwc3: remove the call trace of USBx_GFLADJ
        usb: gadget: configfs: fix concurrent issue between composite APIs
        ...
      3a69c9e5
  7. 02 Nov, 2019 4 commits