1. 10 Aug, 2018 4 commits
    • 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
  2. 07 Aug, 2018 1 commit
  3. 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
  4. 02 Aug, 2018 4 commits
  5. 01 Aug, 2018 4 commits
  6. 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
  7. 30 Jul, 2018 5 commits
  8. 27 Jul, 2018 2 commits
  9. 26 Jul, 2018 11 commits
  10. 25 Jul, 2018 4 commits
    • Artem Savkov's avatar
      tracing/kprobes: Fix trace_probe flags on enable_trace_kprobe() failure · 57ea2a34
      Artem Savkov authored
      If enable_trace_kprobe fails to enable the probe in enable_k(ret)probe
      it returns an error, but does not unset the tp flags it set previously.
      This results in a probe being considered enabled and failures like being
      unable to remove the probe through kprobe_events file since probes_open()
      expects every probe to be disabled.
      
      Link: http://lkml.kernel.org/r/20180725102826.8300-1-asavkov@redhat.com
      Link: http://lkml.kernel.org/r/20180725142038.4765-1-asavkov@redhat.com
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: 41a7dd42 ("tracing/kprobes: Support ftrace_event_file base multibuffer")
      Acked-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: default avatarJosh Poimboeuf <jpoimboe@redhat.com>
      Signed-off-by: default avatarArtem Savkov <asavkov@redhat.com>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      57ea2a34
    • Masami Hiramatsu's avatar
      selftests/ftrace: Add snapshot and tracing_on test case · 82f4f3e6
      Masami Hiramatsu authored
      Add a testcase for checking snapshot and tracing_on
      relationship. This ensures that the snapshotting doesn't
      affect current tracing on/off settings.
      
      Link: http://lkml.kernel.org/r/153149932412.11274.15289227592627901488.stgit@devbox
      
      Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
      Cc: Hiraku Toyooka <hiraku.toyooka@cybertrust.co.jp>
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: linux-kselftest@vger.kernel.org
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      82f4f3e6
    • Masami Hiramatsu's avatar
      ring_buffer: tracing: Inherit the tracing setting to next ring buffer · 73c8d894
      Masami Hiramatsu authored
      Maintain the tracing on/off setting of the ring_buffer when switching
      to the trace buffer snapshot.
      
      Taking a snapshot is done by swapping the backup ring buffer
      (max_tr_buffer). But since the tracing on/off setting is defined
      by the ring buffer, when swapping it, the tracing on/off setting
      can also be changed. This causes a strange result like below:
      
        /sys/kernel/debug/tracing # cat tracing_on
        1
        /sys/kernel/debug/tracing # echo 0 > tracing_on
        /sys/kernel/debug/tracing # cat tracing_on
        0
        /sys/kernel/debug/tracing # echo 1 > snapshot
        /sys/kernel/debug/tracing # cat tracing_on
        1
        /sys/kernel/debug/tracing # echo 1 > snapshot
        /sys/kernel/debug/tracing # cat tracing_on
        0
      
      We don't touch tracing_on, but snapshot changes tracing_on
      setting each time. This is an anomaly, because user doesn't know
      that each "ring_buffer" stores its own tracing-enable state and
      the snapshot is done by swapping ring buffers.
      
      Link: http://lkml.kernel.org/r/153149929558.11274.11730609978254724394.stgit@devbox
      
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Shuah Khan <shuah@kernel.org>
      Cc: Tom Zanussi <tom.zanussi@linux.intel.com>
      Cc: Hiraku Toyooka <hiraku.toyooka@cybertrust.co.jp>
      Cc: stable@vger.kernel.org
      Fixes: debdd57f ("tracing: Make a snapshot feature available from userspace")
      Signed-off-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      [ Updated commit log and comment in the code ]
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      73c8d894
    • Steven Rostedt (VMware)'s avatar
      tracing: Fix double free of event_trigger_data · 1863c387
      Steven Rostedt (VMware) authored
      Running the following:
      
       # cd /sys/kernel/debug/tracing
       # echo 500000 > buffer_size_kb
      [ Or some other number that takes up most of memory ]
       # echo snapshot > events/sched/sched_switch/trigger
      
      Triggers the following bug:
      
       ------------[ cut here ]------------
       kernel BUG at mm/slub.c:296!
       invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC PTI
       CPU: 6 PID: 6878 Comm: bash Not tainted 4.18.0-rc6-test+ #1066
       Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v03.03 07/14/2016
       RIP: 0010:kfree+0x16c/0x180
       Code: 05 41 0f b6 72 51 5b 5d 41 5c 4c 89 d7 e9 ac b3 f8 ff 48 89 d9 48 89 da 41 b8 01 00 00 00 5b 5d 41 5c 4c 89 d6 e9 f4 f3 ff ff <0f> 0b 0f 0b 48 8b 3d d9 d8 f9 00 e9 c1 fe ff ff 0f 1f 40 00 0f 1f
       RSP: 0018:ffffb654436d3d88 EFLAGS: 00010246
       RAX: ffff91a9d50f3d80 RBX: ffff91a9d50f3d80 RCX: ffff91a9d50f3d80
       RDX: 00000000000006a4 RSI: ffff91a9de5a60e0 RDI: ffff91a9d9803500
       RBP: ffffffff8d267c80 R08: 00000000000260e0 R09: ffffffff8c1a56be
       R10: fffff0d404543cc0 R11: 0000000000000389 R12: ffffffff8c1a56be
       R13: ffff91a9d9930e18 R14: ffff91a98c0c2890 R15: ffffffff8d267d00
       FS:  00007f363ea64700(0000) GS:ffff91a9de580000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: 000055c1cacc8e10 CR3: 00000000d9b46003 CR4: 00000000001606e0
       Call Trace:
        event_trigger_callback+0xee/0x1d0
        event_trigger_write+0xfc/0x1a0
        __vfs_write+0x33/0x190
        ? handle_mm_fault+0x115/0x230
        ? _cond_resched+0x16/0x40
        vfs_write+0xb0/0x190
        ksys_write+0x52/0xc0
        do_syscall_64+0x5a/0x160
        entry_SYSCALL_64_after_hwframe+0x49/0xbe
       RIP: 0033:0x7f363e16ab50
       Code: 73 01 c3 48 8b 0d 38 83 2c 00 f7 d8 64 89 01 48 83 c8 ff c3 66 0f 1f 44 00 00 83 3d 79 db 2c 00 00 75 10 b8 01 00 00 00 0f 05 <48> 3d 01 f0 ff ff 73 31 c3 48 83 ec 08 e8 1e e3 01 00 48 89 04 24
       RSP: 002b:00007fff9a4c6378 EFLAGS: 00000246 ORIG_RAX: 0000000000000001
       RAX: ffffffffffffffda RBX: 0000000000000009 RCX: 00007f363e16ab50
       RDX: 0000000000000009 RSI: 000055c1cacc8e10 RDI: 0000000000000001
       RBP: 000055c1cacc8e10 R08: 00007f363e435740 R09: 00007f363ea64700
       R10: 0000000000000073 R11: 0000000000000246 R12: 0000000000000009
       R13: 0000000000000001 R14: 00007f363e4345e0 R15: 00007f363e4303c0
       Modules linked in: ip6table_filter ip6_tables snd_hda_codec_hdmi snd_hda_codec_realtek snd_hda_codec_generic snd_hda_intel snd_hda_codec snd_hwdep snd_hda_core snd_seq snd_seq_device i915 snd_pcm snd_timer i2c_i801 snd soundcore i2c_algo_bit drm_kms_helper
      86_pkg_temp_thermal video kvm_intel kvm irqbypass wmi e1000e
       ---[ end trace d301afa879ddfa25 ]---
      
      The cause is because the register_snapshot_trigger() call failed to
      allocate the snapshot buffer, and then called unregister_trigger()
      which freed the data that was passed to it. Then on return to the
      function that called register_snapshot_trigger(), as it sees it
      failed to register, it frees the trigger_data again and causes
      a double free.
      
      By calling event_trigger_init() on the trigger_data (which only ups
      the reference counter for it), and then event_trigger_free() afterward,
      the trigger_data would not get freed by the registering trigger function
      as it would only up and lower the ref count for it. If the register
      trigger function fails, then the event_trigger_free() called after it
      will free the trigger data normally.
      
      Link: http://lkml.kernel.org/r/20180724191331.738eb819@gandalf.local.home
      
      Cc: stable@vger.kerne.org
      Fixes: 93e31ffb ("tracing: Add 'snapshot' event trigger command")
      Reported-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Reviewed-by: default avatarMasami Hiramatsu <mhiramat@kernel.org>
      Signed-off-by: default avatarSteven Rostedt (VMware) <rostedt@goodmis.org>
      1863c387
  11. 22 Jul, 2018 2 commits
    • Linus Torvalds's avatar
      Linux 4.18-rc6 · d72e90f3
      Linus Torvalds authored
      d72e90f3
    • Linus Torvalds's avatar
      Merge tag 'nvme-for-4.18' of git://git.infradead.org/nvme · 74413084
      Linus Torvalds authored
      Pull NVMe fixes from Christoph Hellwig:
      
       - fix a regression in 4.18 that causes a memory leak on probe failure
         (Keith Bush)
      
       - fix a deadlock in the passthrough ioctl code (Scott Bauer)
      
       - don't enable AENs if not supported (Weiping Zhang)
      
       - fix an old regression in metadata handling in the passthrough ioctl
         code (Roland Dreier)
      
      * tag 'nvme-for-4.18' of git://git.infradead.org/nvme:
        nvme: fix handling of metadata_len for NVME_IOCTL_IO_CMD
        nvme: don't enable AEN if not supported
        nvme: ensure forward progress during Admin passthru
        nvme-pci: fix memory leak on probe failure
      74413084