1. 16 Aug, 2018 3 commits
  2. 14 Aug, 2018 2 commits
  3. 10 Aug, 2018 7 commits
    • Steven Rostedt (VMware)'s avatar
      tracepoints: Free early tracepoints after RCU is initialized · f8a79d5c
      Steven Rostedt (VMware) authored
      When enabling trace events via the kernel command line, I hit this warning:
      
      WARNING: CPU: 0 PID: 13 at kernel/rcu/srcutree.c:236 check_init_srcu_struct+0xe/0x61
      Modules linked in:
      CPU: 0 PID: 13 Comm: watchdog/0 Not tainted 4.18.0-rc6-test+ #6
      Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
      RIP: 0010:check_init_srcu_struct+0xe/0x61
      Code: 48 c7 c6 ec 8a 65 b4 e8 ff 79 fe ff 48 89 df 31 f6 e8 f2 fa ff ff 5a
      5b 41 5c 5d c3 0f 1f 44 00 00 83 3d 68 94 b8 01 01 75 02 <0f> 0b 48 8b 87 f0
      0a 00 00 a8 03 74 45 55 48 89 e5 41 55 41 54 4c
      RSP: 0000:ffff96eb9ea03e68 EFLAGS: 00010246
      RAX: ffff96eb962b5b01 RBX: ffffffffb4a87420 RCX: 0000000000000001
      RDX: ffffffffb3107969 RSI: ffff96eb962b5b40 RDI: ffffffffb4a87420
      RBP: ffff96eb9ea03eb0 R08: ffffabbd00cd7f48 R09: 0000000000000000
      R10: ffff96eb9ea03e68 R11: ffffffffb4a6eec0 R12: ffff96eb962b5b40
      R13: ffff96eb9ea03ef8 R14: ffffffffb3107969 R15: ffffffffb3107948
      FS:  0000000000000000(0000) GS:ffff96eb9ea00000(0000) knlGS:0000000000000000
      CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
      CR2: ffff96eb13ab2000 CR3: 0000000192a1e001 CR4: 00000000001606f0
      Call Trace:
       <IRQ>
       ? __call_srcu+0x2d/0x290
       ? rcu_process_callbacks+0x26e/0x448
       ? allocate_probes+0x2b/0x2b
       call_srcu+0x13/0x15
       rcu_free_old_probes+0x1f/0x21
       rcu_process_callbacks+0x2ed/0x448
       __do_softirq+0x172/0x336
       irq_exit+0x62/0xb2
       smp_apic_timer_interrupt+0x161/0x19e
       apic_timer_interrupt+0xf/0x20
       </IRQ>
      
      The problem is that the enabling of trace events before RCU is set up will
      cause SRCU to give this warning. To avoid this, add a list to store probes
      that need to be freed till after RCU is initialized, and then free them
      then.
      
      Link: http://lkml.kernel.org/r/20180810113554.1df28050@gandalf.local.home
      Link: http://lkml.kernel.org/r/20180810123517.5e9714ad@gandalf.local.homeAcked-by: default avatarPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Reviewed-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Fixes: e6753f23 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      f8a79d5c
    • Steven Rostedt (VMware)'s avatar
      uprobes: Use synchronize_rcu() not synchronize_sched() · 016f8ffc
      Steven Rostedt (VMware) authored
      While debugging another bug, I was looking at all the synchronize*()
      functions being used in kernel/trace, and noticed that trace_uprobes was
      using synchronize_sched(), with a comment to synchronize with
      {u,ret}_probe_trace_func(). When looking at those functions, the data is
      protected with "rcu_read_lock()" and not with "rcu_read_lock_sched()". This
      is using the wrong synchronize_*() function.
      
      Link: http://lkml.kernel.org/r/20180809160553.469e1e32@gandalf.local.home
      
      Cc: stable@vger.kernel.org
      Fixes: 70ed91c6 ("tracing/uprobes: Support ftrace_event_file base multibuffer")
      Acked-by: default avatarOleg Nesterov <oleg@redhat.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      016f8ffc
    • Steven Rostedt (VMware)'s avatar
      tracing: Fix synchronizing to event changes with tracepoint_synchronize_unregister() · e0a568dc
      Steven Rostedt (VMware) authored
      Now that some trace events can be protected by srcu_read_lock(tracepoint_srcu),
      we need to make sure all locations that depend on this are also protected.
      There were many places that did a synchronize_sched() thinking that it was
      enough to protect againts access to trace events. This use to be the case,
      but now that we use SRCU for _rcuidle() trace events, they may not be
      protected by synchronize_sched(), as they may be called in paths that RCU is
      not watching for preempt disable.
      
      Fixes: e6753f23 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      e0a568dc
    • Colin Ian King's avatar
      ftrace: Remove unused pointer ftrace_swapper_pid · b207de3e
      Colin Ian King authored
      Pointer ftrace_swapper_pid is defined but is never used hence it is
      redundant and can be removed. The use of this variable was removed
      in commit 345ddcc8 ("ftrace: Have set_ftrace_pid use the bitmap
      like events do").
      
      Cleans up clang warning:
      warning: 'ftrace_swapper_pid' defined but not used [-Wunused-const-variable=]
      
      Link: http://lkml.kernel.org/r/20180809125609.13142-1-colin.king@canonical.comSigned-off-by: default avatarColin Ian King <colin.king@canonical.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      b207de3e
    • Steven Rostedt (VMware)'s avatar
      tracing: More reverting of "tracing: Centralize preemptirq tracepoints and unify their usage" · 3f1756dc
      Steven Rostedt (VMware) authored
      Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
      by lockdep and irqsoff latency tracer. It made both use tracepoints. But the
      latency tracer is triggering warnings when using tracepoints to call into
      the latency tracer's routines. Mainly, they can be called from NMI context.
      If that happens, then the SRCU may not work properly because on some
      architectures, SRCU is not safe to be called in both NMI and non-NMI
      context.
      
      This is a partial revert of the clean up patch c3bc8fd6 ("tracing:
      Centralize preemptirq tracepoints and unify their usage") that adds back the
      direct calls into the latency tracer. It also only calls the trace events
      when not in NMI.
      
      Link: http://lkml.kernel.org/r/20180809210654.622445925@goodmis.orgReviewed-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Fixes: c3bc8fd6 ("tracing: Centralize preemptirq tracepoints and unify their usage")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      3f1756dc
    • Steven Rostedt (VMware)'s avatar
      tracing/irqsoff: Handle preempt_count for different configs · f27107fa
      Steven Rostedt (VMware) authored
      I was hitting the following warning:
      
      WARNING: CPU: 0 PID: 1 at kernel/trace/trace_irqsoff.c:631 tracer_hardirqs_off+0x15/0x2a
      
      Modules linked in:
      CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.18.0-rc6-test+ #13
      Hardware name: MSI MS-7823/CSM-H87M-G43 (MS-7823), BIOS V1.6 02/22/2014
      EIP: tracer_hardirqs_off+0x15/0x2a
      Code: ff 85 c0 74 0e 8b 45 00 8b 50 04 8b 45 04 e8 35 ff ff ff 5d c3 55 64 a1 cc 37 51 c1 a9 ff ff ff 7f 89 e5 53 89 d3 89 ca 75 02 <0f> 0b e8 90 fc ff ff 85 c0 74 07 89 d8 e8 0c ff ff ff 5b 5d c3 55
      EAX: 80000000 EBX: c04337f0 ECX: c04338e3 EDX: c04338e3
      ESI: c04337f0 EDI: c04338e3 EBP: f2aa1d68 ESP: f2aa1d64
      DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00210046
      CR0: 80050033 CR2: 00000000 CR3: 01668000 CR4: 001406f0
      Call Trace:
       trace_irq_disable_rcuidle+0x63/0x6c
       trace_hardirqs_off+0x26/0x30
       default_send_IPI_mask_allbutself_logical+0x31/0x93
       default_send_IPI_allbutself+0x37/0x48
       native_send_call_func_ipi+0x4d/0x6a
       smp_call_function_many+0x165/0x19d
       ? add_nops+0x34/0x34
       ? trace_hardirqs_on_caller+0x2d/0x2d
       ? add_nops+0x34/0x34
       smp_call_function+0x1f/0x23
       on_each_cpu+0x15/0x43
       ? trace_hardirqs_on_caller+0x2d/0x2d
       ? trace_hardirqs_on_caller+0x2d/0x2d
       ? trace_irq_disable_rcuidle+0x1/0x6c
       text_poke_bp+0xa0/0xc2
       ? trace_hardirqs_on_caller+0x2d/0x2d
       arch_jump_label_transform+0xa7/0xcb
       ? trace_irq_disable_rcuidle+0x5/0x6c
       __jump_label_update+0x3e/0x6d
       jump_label_update+0x7d/0x81
       static_key_slow_inc_cpuslocked+0x58/0x6d
       static_key_slow_inc+0x19/0x20
       tracepoint_probe_register_prio+0x19e/0x1d1
       ? start_critical_timings+0x1c/0x1c
       tracepoint_probe_register+0xf/0x11
       irqsoff_tracer_init+0x21/0xf2
       tracer_init+0x16/0x1a
       trace_selftest_startup_irqsoff+0x25/0xc4
       run_tracer_selftest+0xca/0x131
       register_tracer+0xd5/0x172
       ? trace_event_define_fields_preemptirq_template+0x45/0x45
       init_irqsoff_tracer+0xd/0x11
       do_one_initcall+0xab/0x1e8
       ? rcu_read_lock_sched_held+0x3d/0x44
       ? trace_initcall_level+0x52/0x86
       kernel_init_freeable+0x195/0x21a
       ? rest_init+0xb4/0xb4
       kernel_init+0xd/0xe4
       ret_from_fork+0x2e/0x38
      
      It is due to running a CONFIG_PREEMPT_VOLUNTARY kernel, which would trigger
      this warning every time:
      
      	WARN_ON_ONCE(preempt_count());
      
      Because on CONFIG_PREEMPT_VOLUNTARY, preempt_count() is always zero.
      
      This warning is to make sure preempt_count is set because
      tracer_hardirqs_on() does a preempt_enable_notrace() to make the
      preempt_trace() work properly, as being called by a trace event, the trace
      event code disables preemption, and the tracer wants to know what the
      preemption was before it was called.
      
      Instead of enabling preemption like this, just record the preempt_count,
      subtract PREEMPT_DISABLE_OFFSET from it (which is zero with !CONFIG_PREEMPT
      set), and pass that value to the necessary functions, which should use the
      passed in parameter instead of calling preempt_count() directly.
      
      Fixes: da5b3ebb ("tracing: irqsoff: Account for additional preempt_disable")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      f27107fa
    • Steven Rostedt (VMware)'s avatar
      tracing: Partial revert of "tracing: Centralize preemptirq tracepoints and unify their usage" · bff1b208
      Steven Rostedt (VMware) authored
      Joel Fernandes created a nice patch that cleaned up the duplicate hooks used
      by lockdep and irqsoff latency tracer. It made both use tracepoints. But it
      caused lockdep to trigger several false positives. We have not figured out
      why yet, but removing lockdep from using the trace event hooks and just call
      its helper functions directly (like it use to), makes the problem go away.
      
      This is a partial revert of the clean up patch c3bc8fd6 ("tracing:
      Centralize preemptirq tracepoints and unify their usage") that adds direct
      calls for lockdep, but also keeps most of the clean up done to get rid of
      the horrible preprocessor if statements.
      
      Link: http://lkml.kernel.org/r/20180806155058.5ee875f4@gandalf.local.home
      
      Cc: Peter Zijlstra <peterz@infradead.org>
      Reviewed-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Fixes: c3bc8fd6 ("tracing: Centralize preemptirq tracepoints and unify their usage")
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      bff1b208
  4. 07 Aug, 2018 1 commit
  5. 03 Aug, 2018 1 commit
    • Joel Fernandes (Google)'s avatar
      trace: Use rcu_dereference_raw for hooks from trace-event subsystem · da25a672
      Joel Fernandes (Google) authored
      Since we switched to using SRCU for tracepoints used in the idle path,
      we can no longer use rcu_dereference_sched for dereferencing points in
      trace-event hooks.
      
      Since tracepoints can now use either SRCU or sched-RCU, just use
      rcu_dereference_raw for traceevents just like we're doing when
      dereferencing the tracepoint table.
      
      This prevents an RCU warning reported by Masami:
      
      [  282.060593] WARNING: can't dereference registers at 00000000f3c7f62b
      [  282.063200] =============================
      [  282.064082] WARNING: suspicious RCU usage
      [  282.064963] 4.18.0-rc6+ #15 Tainted: G        W
      [  282.066048] -----------------------------
      [  282.066923] /home/mhiramat/ksrc/linux/kernel/trace/trace_events.c:242
      				suspicious rcu_dereference_check() usage!
      [  282.068974]
      [  282.068974] other info that might help us debug this:
      [  282.068974]
      [  282.070770]
      [  282.070770] RCU used illegally from idle CPU!
      [  282.070770] rcu_scheduler_active = 2, debug_locks = 1
      [  282.072938] RCU used illegally from extended quiescent state!
      [  282.074183] no locks held by swapper/0/0.
      [  282.075071]
      [  282.075071] stack backtrace:
      [  282.076121] CPU: 0 PID: 0 Comm: swapper/0 Tainted: G        W
      [  282.077782] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996)
      [  282.079604] Call Trace:
      [  282.080212]  <IRQ>
      [  282.080755]  dump_stack+0x85/0xcb
      [  282.081523]  trace_event_ignore_this_pid+0x66/0x70
      [  282.082541]  trace_event_raw_event_preemptirq_template+0xa2/0xb0
      [  282.083774]  ? interrupt_entry+0xc4/0xe0
      [  282.084665]  ? trace_hardirqs_off_thunk+0x1a/0x1c
      [  282.085669]  trace_hardirqs_off_caller+0x90/0xd0
      [  282.086597]  trace_hardirqs_off_thunk+0x1a/0x1c
      [  282.087433]  ? call_function_interrupt+0xa/0x20
      [  282.088201]  interrupt_entry+0xc4/0xe0
      [  282.088848]  ? call_function_interrupt+0xa/0x20
      [  282.089579]  </IRQ>
      [  282.090029]  ? native_safe_halt+0x2/0x10
      [  282.090695]  ? default_idle+0x1f/0x160
      [  282.091330]  ? default_idle_call+0x24/0x40
      [  282.091997]  ? do_idle+0x210/0x250
      [  282.092658]  ? cpu_startup_entry+0x6f/0x80
      [  282.093338]  ? start_kernel+0x49d/0x4bd
      [  282.093987]  ? secondary_startup_64+0xa5/0xb0
      
      Link: http://lkml.kernel.org/r/20180803023407.225852-1-joel@joelfernandes.orgReported-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Tested-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Fixes: e6753f23 ("tracepoint: Make rcuidle tracepoint callers use SRCU")
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      da25a672
  6. 02 Aug, 2018 4 commits
  7. 01 Aug, 2018 4 commits
  8. 31 Jul, 2018 2 commits
    • Zubin Mithra's avatar
      tracefs: Annotate tracefs_ops with __ro_after_init · 5248ee85
      Zubin Mithra authored
      tracefs_ops is initialized inside tracefs_create_instance_dir and not
      modified after. tracefs_create_instance_dir allows for initialization
      only once, and is called from create_trace_instances(marked __init),
      which is called from tracer_init_tracefs(marked __init). Also, mark
      tracefs_create_instance_dir as __init.
      
      Link: http://lkml.kernel.org/r/20180725171901.4468-1-zsm@chromium.orgReviewed-by: default avatarKees Cook <keescook@chromium.org>
      Signed-off-by: default avatarZubin Mithra <zsm@chromium.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      5248ee85
    • Joel Fernandes (Google)'s avatar
      tracing: Centralize preemptirq tracepoints and unify their usage · c3bc8fd6
      Joel Fernandes (Google) authored
      This patch detaches the preemptirq tracepoints from the tracers and
      keeps it separate.
      
      Advantages:
      * Lockdep and irqsoff event can now run in parallel since they no longer
      have their own calls.
      
      * This unifies the usecase of adding hooks to an irqsoff and irqson
      event, and a preemptoff and preempton event.
        3 users of the events exist:
        - Lockdep
        - irqsoff and preemptoff tracers
        - irqs and preempt trace events
      
      The unification cleans up several ifdefs and makes the code in preempt
      tracer and irqsoff tracers simpler. It gets rid of all the horrific
      ifdeferry around PROVE_LOCKING and makes configuration of the different
      users of the tracepoints more easy and understandable. It also gets rid
      of the time_* function calls from the lockdep hooks used to call into
      the preemptirq tracer which is not needed anymore. The negative delta in
      lines of code in this patch is quite large too.
      
      In the patch we introduce a new CONFIG option PREEMPTIRQ_TRACEPOINTS
      as a single point for registering probes onto the tracepoints. With
      this,
      the web of config options for preempt/irq toggle tracepoints and its
      users becomes:
      
       PREEMPT_TRACER   PREEMPTIRQ_EVENTS  IRQSOFF_TRACER PROVE_LOCKING
             |                 |     \         |           |
             \    (selects)    /      \        \ (selects) /
            TRACE_PREEMPT_TOGGLE       ----> TRACE_IRQFLAGS
                            \                  /
                             \ (depends on)   /
                           PREEMPTIRQ_TRACEPOINTS
      
      Other than the performance tests mentioned in the previous patch, I also
      ran the locking API test suite. I verified that all tests cases are
      passing.
      
      I also injected issues by not registering lockdep probes onto the
      tracepoints and I see failures to confirm that the probes are indeed
      working.
      
      This series + lockdep probes not registered (just to inject errors):
      [    0.000000]      hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
      [    0.000000]      soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
      [    0.000000]        sirq-safe-A => hirqs-on/12:FAILED|FAILED|  ok  |
      [    0.000000]        sirq-safe-A => hirqs-on/21:FAILED|FAILED|  ok  |
      [    0.000000]          hard-safe-A + irqs-on/12:FAILED|FAILED|  ok  |
      [    0.000000]          soft-safe-A + irqs-on/12:FAILED|FAILED|  ok  |
      [    0.000000]          hard-safe-A + irqs-on/21:FAILED|FAILED|  ok  |
      [    0.000000]          soft-safe-A + irqs-on/21:FAILED|FAILED|  ok  |
      [    0.000000]     hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
      [    0.000000]     soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
      
      With this series + lockdep probes registered, all locking tests pass:
      
      [    0.000000]      hard-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
      [    0.000000]      soft-irqs-on + irq-safe-A/21:  ok  |  ok  |  ok  |
      [    0.000000]        sirq-safe-A => hirqs-on/12:  ok  |  ok  |  ok  |
      [    0.000000]        sirq-safe-A => hirqs-on/21:  ok  |  ok  |  ok  |
      [    0.000000]          hard-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
      [    0.000000]          soft-safe-A + irqs-on/12:  ok  |  ok  |  ok  |
      [    0.000000]          hard-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
      [    0.000000]          soft-safe-A + irqs-on/21:  ok  |  ok  |  ok  |
      [    0.000000]     hard-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
      [    0.000000]     soft-safe-A + unsafe-B #1/123:  ok  |  ok  |  ok  |
      
      Link: http://lkml.kernel.org/r/20180730222423.196630-4-joel@joelfernandes.orgAcked-by: default avatarPeter Zijlstra (Intel) <peterz@infradead.org>
      Reviewed-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Signed-off-by: default avatarJoel Fernandes (Google) <joel@joelfernandes.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      c3bc8fd6
  9. 30 Jul, 2018 5 commits
  10. 27 Jul, 2018 2 commits
  11. 26 Jul, 2018 9 commits