1. 29 Mar, 2023 8 commits
    • Beau Belgrave's avatar
      tracing/user_events: Fixup enable faults asyncly · 81f8fb65
      Beau Belgrave authored
      When events are enabled within the various tracing facilities, such as
      ftrace/perf, the event_mutex is held. As events are enabled pages are
      accessed. We do not want page faults to occur under this lock. Instead
      queue the fault to a workqueue to be handled in a process context safe
      way without the lock.
      
      The enable address is marked faulting while the async fault-in occurs.
      This ensures that we don't attempt to fault-in more than is necessary.
      Once the page has been faulted in, an address write is re-attempted.
      If the page couldn't fault-in, then we wait until the next time the
      event is enabled to prevent any potential infinite loops.
      
      Link: https://lkml.kernel.org/r/20230328235219.203-5-beaub@linux.microsoft.comSigned-off-by: default avatarBeau Belgrave <beaub@linux.microsoft.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      81f8fb65
    • Beau Belgrave's avatar
      tracing/user_events: Use remote writes for event enablement · 72357590
      Beau Belgrave authored
      As part of the discussions for user_events aligned with user space
      tracers, it was determined that user programs should register a aligned
      value to set or clear a bit when an event becomes enabled. Currently a
      shared page is being used that requires mmap(). Remove the shared page
      implementation and move to a user registered address implementation.
      
      In this new model during the event registration from user programs 3 new
      values are specified. The first is the address to update when the event
      is either enabled or disabled. The second is the bit to set/clear to
      reflect the event being enabled. The third is the size of the value at
      the specified address.
      
      This allows for a local 32/64-bit value in user programs to support
      both kernel and user tracers. As an example, setting bit 31 for kernel
      tracers when the event becomes enabled allows for user tracers to use
      the other bits for ref counts or other flags. The kernel side updates
      the bit atomically, user programs need to also update these values
      atomically.
      
      User provided addresses must be aligned on a natural boundary, this
      allows for single page checking and prevents odd behaviors such as a
      enable value straddling 2 pages instead of a single page. Currently
      page faults are only logged, future patches will handle these.
      
      Link: https://lkml.kernel.org/r/20230328235219.203-4-beaub@linux.microsoft.comSuggested-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarBeau Belgrave <beaub@linux.microsoft.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      72357590
    • Beau Belgrave's avatar
      tracing/user_events: Track fork/exec/exit for mm lifetime · fd593511
      Beau Belgrave authored
      During tracefs discussions it was decided instead of requiring a mapping
      within a user-process to track the lifetime of memory descriptors we
      should hook the appropriate calls. Do this by adding the minimal stubs
      required for task fork, exec, and exit. Currently this is just a NOP.
      Future patches will implement these calls fully.
      
      Link: https://lkml.kernel.org/r/20230328235219.203-3-beaub@linux.microsoft.comSuggested-by: default avatarMathieu Desnoyers <mathieu.desnoyers@efficios.com>
      Signed-off-by: default avatarBeau Belgrave <beaub@linux.microsoft.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      fd593511
    • Beau Belgrave's avatar
      tracing/user_events: Split header into uapi and kernel · e5a26a40
      Beau Belgrave authored
      The UAPI parts need to be split out from the kernel parts of user_events
      now that other parts of the kernel will reference it. Do so by moving
      the existing include/linux/user_events.h into
      include/uapi/linux/user_events.h.
      
      Link: https://lkml.kernel.org/r/20230328235219.203-2-beaub@linux.microsoft.comSigned-off-by: default avatarBeau Belgrave <beaub@linux.microsoft.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      e5a26a40
    • Steven Rostedt (Google)'s avatar
      tracing: Add "fields" option to show raw trace event fields · 80a76994
      Steven Rostedt (Google) authored
      The hex, raw and bin formats come from the old PREEMPT_RT patch set
      latency tracer. That actually gave real alternatives to reading the ascii
      buffer. But they have started to bit rot and they do not give a good
      representation of the tracing data.
      
      Add "fields" option that will read the trace event fields and parse the
      data from how the fields are defined:
      
      With "fields" = 0 (default)
      
       echo 1 > events/sched/sched_switch/enable
       cat trace
               <idle>-0       [003] d..2.   540.078653: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/3:1 next_pid=83 next_prio=120
           kworker/3:1-83      [003] d..2.   540.078860: sched_switch: prev_comm=kworker/3:1 prev_pid=83 prev_prio=120 prev_state=I ==> next_comm=swapper/3 next_pid=0 next_prio=120
                <idle>-0       [003] d..2.   540.206423: sched_switch: prev_comm=swapper/3 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=sshd next_pid=807 next_prio=120
                  sshd-807     [003] d..2.   540.206531: sched_switch: prev_comm=sshd prev_pid=807 prev_prio=120 prev_state=S ==> next_comm=swapper/3 next_pid=0 next_prio=120
                <idle>-0       [001] d..2.   540.206597: sched_switch: prev_comm=swapper/1 prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=kworker/u16:4 next_pid=58 next_prio=120
         kworker/u16:4-58      [001] d..2.   540.206617: sched_switch: prev_comm=kworker/u16:4 prev_pid=58 prev_prio=120 prev_state=I ==> next_comm=bash next_pid=830 next_prio=120
                  bash-830     [001] d..2.   540.206678: sched_switch: prev_comm=bash prev_pid=830 prev_prio=120 prev_state=R ==> next_comm=kworker/u16:4 next_pid=58 next_prio=120
         kworker/u16:4-58      [001] d..2.   540.206696: sched_switch: prev_comm=kworker/u16:4 prev_pid=58 prev_prio=120 prev_state=I ==> next_comm=bash next_pid=830 next_prio=120
                  bash-830     [001] d..2.   540.206713: sched_switch: prev_comm=bash prev_pid=830 prev_prio=120 prev_state=R ==> next_comm=kworker/u16:4 next_pid=58 next_prio=120
      
       echo 1 > options/fields
                 <...>-998     [002] d..2.   538.643732: sched_switch: next_prio=0x78 (120) next_pid=0x0 (0) next_comm=swapper/2 prev_state=0x20 (32) prev_prio=0x78 (120) prev_pid=0x3e6 (998) prev_comm=trace-cmd
                <idle>-0       [001] d..2.   538.643806: sched_switch: next_prio=0x78 (120) next_pid=0x33e (830) next_comm=bash prev_state=0x0 (0) prev_prio=0x78 (120) prev_pid=0x0 (0) prev_comm=swapper/1
                  bash-830     [001] d..2.   538.644106: sched_switch: next_prio=0x78 (120) next_pid=0x3a (58) next_comm=kworker/u16:4 prev_state=0x0 (0) prev_prio=0x78 (120) prev_pid=0x33e (830) prev_comm=bash
         kworker/u16:4-58      [001] d..2.   538.644130: sched_switch: next_prio=0x78 (120) next_pid=0x33e (830) next_comm=bash prev_state=0x80 (128) prev_prio=0x78 (120) prev_pid=0x3a (58) prev_comm=kworker/u16:4
                  bash-830     [001] d..2.   538.644180: sched_switch: next_prio=0x78 (120) next_pid=0x3a (58) next_comm=kworker/u16:4 prev_state=0x0 (0) prev_prio=0x78 (120) prev_pid=0x33e (830) prev_comm=bash
         kworker/u16:4-58      [001] d..2.   538.644185: sched_switch: next_prio=0x78 (120) next_pid=0x33e (830) next_comm=bash prev_state=0x80 (128) prev_prio=0x78 (120) prev_pid=0x3a (58) prev_comm=kworker/u16:4
                  bash-830     [001] d..2.   538.644204: sched_switch: next_prio=0x78 (120) next_pid=0x0 (0) next_comm=swapper/1 prev_state=0x1 (1) prev_prio=0x78 (120) prev_pid=0x33e (830) prev_comm=bash
                <idle>-0       [003] d..2.   538.644211: sched_switch: next_prio=0x78 (120) next_pid=0x327 (807) next_comm=sshd prev_state=0x0 (0) prev_prio=0x78 (120) prev_pid=0x0 (0) prev_comm=swapper/3
                  sshd-807     [003] d..2.   538.644340: sched_switch: next_prio=0x78 (120) next_pid=0x0 (0) next_comm=swapper/3 prev_state=0x1 (1) prev_prio=0x78 (120) prev_pid=0x327 (807) prev_comm=sshd
      
      It traces the data safely without using the trace print formatting.
      
      Link: https://lore.kernel.org/linux-trace-kernel/20230328145156.497651be@gandalf.local.home
      
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Beau Belgrave <beaub@linux.microsoft.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      80a76994
    • Ross Zwisler's avatar
      tools/kvm_stat: use canonical ftrace path · c2f92e8b
      Ross Zwisler authored
      The canonical location for the tracefs filesystem is at /sys/kernel/tracing.
      
      But, from Documentation/trace/ftrace.rst:
      
        Before 4.1, all ftrace tracing control files were within the debugfs
        file system, which is typically located at /sys/kernel/debug/tracing.
        For backward compatibility, when mounting the debugfs file system,
        the tracefs file system will be automatically mounted at:
      
        /sys/kernel/debug/tracing
      
      A comment in kvm_stat still refers to this older debugfs path, so let's
      update it to avoid confusion.
      
      Link: https://lkml.kernel.org/r/20230313211746.1541525-3-zwisler@kernel.org
      
      Cc: "Tobin C. Harding" <me@tobin.cc>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Tycho Andersen <tycho@tycho.pizza>
      Acked-by: default avatarPaolo Bonzini <pbonzini@redhat.com>
      Reviewed-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Reviewed-by: default avatarMukesh Ojha <quic_mojha@quicinc.com>
      Signed-off-by: default avatarRoss Zwisler <zwisler@google.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      c2f92e8b
    • Ross Zwisler's avatar
      leaking_addresses: also skip canonical ftrace path · d1c27c55
      Ross Zwisler authored
      The canonical location for the tracefs filesystem is at /sys/kernel/tracing.
      
      But, from Documentation/trace/ftrace.rst:
      
        Before 4.1, all ftrace tracing control files were within the debugfs
        file system, which is typically located at /sys/kernel/debug/tracing.
        For backward compatibility, when mounting the debugfs file system,
        the tracefs file system will be automatically mounted at:
      
        /sys/kernel/debug/tracing
      
      scripts/leaking_addresses.pl only skipped this older debugfs path, so
      let's add the canonical path as well.
      
      Link: https://lkml.kernel.org/r/20230313211746.1541525-2-zwisler@kernel.org
      
      Cc: "Tobin C. Harding" <me@tobin.cc>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Acked-by: default avatarTycho Andersen <tycho@tycho.pizza>
      Reviewed-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Signed-off-by: default avatarRoss Zwisler <zwisler@google.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      d1c27c55
    • Ross Zwisler's avatar
      selftests: use canonical ftrace path · 4336cc15
      Ross Zwisler authored
      The canonical location for the tracefs filesystem is at /sys/kernel/tracing.
      
      But, from Documentation/trace/ftrace.rst:
      
        Before 4.1, all ftrace tracing control files were within the debugfs
        file system, which is typically located at /sys/kernel/debug/tracing.
        For backward compatibility, when mounting the debugfs file system,
        the tracefs file system will be automatically mounted at:
      
        /sys/kernel/debug/tracing
      
      A few spots in tools/testing/selftests still refer to this older debugfs
      path, so let's update them to avoid confusion.
      
      Link: https://lkml.kernel.org/r/20230313211746.1541525-1-zwisler@kernel.org
      
      Cc: "Tobin C. Harding" <me@tobin.cc>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: Mark Rutland <mark.rutland@arm.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Paolo Bonzini <pbonzini@redhat.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Tycho Andersen <tycho@tycho.pizza>
      Reviewed-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      Reviewed-by: default avatarMukesh Ojha <quic_mojha@quicinc.com>
      Signed-off-by: default avatarRoss Zwisler <zwisler@google.com>
      Signed-off-by: default avatarSteven Rostedt (Google) <rostedt@goodmis.org>
      4336cc15
  2. 28 Mar, 2023 7 commits
  3. 21 Mar, 2023 11 commits
  4. 19 Mar, 2023 14 commits