1. 03 8月, 2017 3 次提交
    • S
      ring-buffer: Have ring_buffer_alloc_read_page() return error on offline CPU · a7e52ad7
      Steven Rostedt (VMware) 提交于
      Chunyu Hu reported:
        "per_cpu trace directories and files are created for all possible cpus,
         but only the cpus which have ever been on-lined have their own per cpu
         ring buffer (allocated by cpuhp threads). While trace_buffers_open, the
         open handler for trace file 'trace_pipe_raw' is always trying to access
         field of ring_buffer_per_cpu, and would panic with the NULL pointer.
      
         Align the behavior of trace_pipe_raw with trace_pipe, that returns -NODEV
         when openning it if that cpu does not have trace ring buffer.
      
         Reproduce:
         cat /sys/kernel/debug/tracing/per_cpu/cpu31/trace_pipe_raw
         (cpu31 is never on-lined, this is a 16 cores x86_64 box)
      
         Tested with:
         1) boot with maxcpus=14, read trace_pipe_raw of cpu15.
            Got -NODEV.
         2) oneline cpu15, read trace_pipe_raw of cpu15.
            Get the raw trace data.
      
         Call trace:
         [ 5760.950995] RIP: 0010:ring_buffer_alloc_read_page+0x32/0xe0
         [ 5760.961678]  tracing_buffers_read+0x1f6/0x230
         [ 5760.962695]  __vfs_read+0x37/0x160
         [ 5760.963498]  ? __vfs_read+0x5/0x160
         [ 5760.964339]  ? security_file_permission+0x9d/0xc0
         [ 5760.965451]  ? __vfs_read+0x5/0x160
         [ 5760.966280]  vfs_read+0x8c/0x130
         [ 5760.967070]  SyS_read+0x55/0xc0
         [ 5760.967779]  do_syscall_64+0x67/0x150
         [ 5760.968687]  entry_SYSCALL64_slow_path+0x25/0x25"
      
      This was introduced by the addition of the feature to reuse reader pages
      instead of re-allocating them. The problem is that the allocation of a
      reader page (which is per cpu) does not check if the cpu is online and set
      up for the ring buffer.
      
      Link: http://lkml.kernel.org/r/1500880866-1177-1-git-send-email-chuhu@redhat.com
      
      Cc: stable@vger.kernel.org
      Fixes: 73a757e6 ("ring-buffer: Return reader page back into existing ring buffer")
      Reported-by: NChunyu Hu <chuhu@redhat.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      a7e52ad7
    • D
      tracing: Missing error code in tracer_alloc_buffers() · 147d88e0
      Dan Carpenter 提交于
      If ring_buffer_alloc() or one of the next couple function calls fail
      then we should return -ENOMEM but the current code returns success.
      
      Link: http://lkml.kernel.org/r/20170801110201.ajdkct7vwzixahvx@mwanda
      
      Cc: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: stable@vger.kernel.org
      Fixes: b32614c0 ('tracing/rb: Convert to hotplug state machine')
      Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      147d88e0
    • S
      tracing: Call clear_boot_tracer() at lateinit_sync · 4bb0f0e7
      Steven Rostedt (VMware) 提交于
      The clear_boot_tracer function is used to reset the default_bootup_tracer
      string to prevent it from being accessed after boot, as it originally points
      to init data. But since clear_boot_tracer() is called via the
      init_lateinit() call, it races with the initcall for registering the hwlat
      tracer. If someone adds "ftrace=hwlat" to the kernel command line, depending
      on how the linker sets up the text, the saved command line may be cleared,
      and the hwlat tracer never is initialized.
      
      Simply have the clear_boot_tracer() be called by initcall_lateinit_sync() as
      that's for tasks to be called after lateinit.
      
      Link: https://bugzilla.kernel.org/show_bug.cgi?id=196551
      
      Cc: stable@vger.kernel.org
      Fixes: e7c15cd8 ("tracing: Added hardware latency tracer")
      Reported-by: NZamir SUN <sztsian@gmail.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      4bb0f0e7
  2. 20 7月, 2017 1 次提交
    • C
      tracing: Fix kmemleak in instance_rmdir · db9108e0
      Chunyu Hu 提交于
      Hit the kmemleak when executing instance_rmdir, it forgot releasing
      mem of tracing_cpumask. With this fix, the warn does not appear any
      more.
      
      unreferenced object 0xffff93a8dfaa7c18 (size 8):
        comm "mkdir", pid 1436, jiffies 4294763622 (age 9134.308s)
        hex dump (first 8 bytes):
          ff ff ff ff ff ff ff ff                          ........
        backtrace:
          [<ffffffff88b6567a>] kmemleak_alloc+0x4a/0xa0
          [<ffffffff8861ea41>] __kmalloc_node+0xf1/0x280
          [<ffffffff88b505d3>] alloc_cpumask_var_node+0x23/0x30
          [<ffffffff88b5060e>] alloc_cpumask_var+0xe/0x10
          [<ffffffff88571ab0>] instance_mkdir+0x90/0x240
          [<ffffffff886e5100>] tracefs_syscall_mkdir+0x40/0x70
          [<ffffffff886565c9>] vfs_mkdir+0x109/0x1b0
          [<ffffffff8865b1d0>] SyS_mkdir+0xd0/0x100
          [<ffffffff88403857>] do_syscall_64+0x67/0x150
          [<ffffffff88b710e7>] return_from_SYSCALL_64+0x0/0x6a
          [<ffffffffffffffff>] 0xffffffffffffffff
      
      Link: http://lkml.kernel.org/r/1500546969-12594-1-git-send-email-chuhu@redhat.com
      
      Cc: stable@vger.kernel.org
      Fixes: ccfe9e42 ("tracing: Make tracing_cpumask available for all instances")
      Signed-off-by: NChunyu Hu <chuhu@redhat.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      db9108e0
  3. 12 7月, 2017 1 次提交
    • S
      tracing: Fixup trace file header alignment · b11fb737
      Steven Rostedt (VMware) 提交于
      The addition of TGID to the tracing header added a check to see if TGID
      shoudl be displayed or not, and updated the header accordingly.
      Unfortunately, it broke the default header.
      
      Also add constant strings to use for spacing. This does remove the
      visibility of the header a bit, but cuts it down from the extended lines
      much greater than 80 characters.
      
      Before this change:
      
       # tracer: function
       #
       #                            _-----=> irqs-off
       #                           / _----=> need-resched
       #                          | / _---=> hardirq/softirq
       #                          || / _--=> preempt-depth
       #                          ||| /     delay
       #           TASK-PID   CPU#||||    TIMESTAMP  FUNCTION
       #              | |       | ||||       |         |
              swapper/0-1     [000] ....     0.277830: migration_init <-do_one_initcall
              swapper/0-1     [002] d...    13.861967: Unknown type 1201
              swapper/0-1     [002] d..1    13.861970: Unknown type 1202
      
      After this change:
      
       # tracer: function
       #
       #                              _-----=> irqs-off
       #                             / _----=> need-resched
       #                            | / _---=> hardirq/softirq
       #                            || / _--=> preempt-depth
       #                            ||| /     delay
       #           TASK-PID   CPU#  ||||    TIMESTAMP  FUNCTION
       #              | |       |   ||||       |         |
              swapper/0-1     [000] ....     0.278245: migration_init <-do_one_initcall
              swapper/0-1     [003] d...    13.861189: Unknown type 1201
              swapper/0-1     [003] d..1    13.861192: Unknown type 1202
      
      Cc: Joel Fernandes <joelaf@google.com>
      Fixes: 441dae8f ("tracing: Add support for display of tgid in trace output")
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      b11fb737
  4. 07 7月, 2017 3 次提交
  5. 06 7月, 2017 1 次提交
  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 3 次提交
  8. 14 6月, 2017 8 次提交
  9. 13 6月, 2017 1 次提交
  10. 08 6月, 2017 1 次提交
  11. 19 5月, 2017 1 次提交
  12. 18 5月, 2017 3 次提交
    • S
      ftrace: Remove #ifdef from code and add clear_ftrace_function_probes() stub · 8a49f3e0
      Steven Rostedt (VMware) 提交于
      No need to add ugly #ifdefs in the code. Having a standard stub file is much
      prettier.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      8a49f3e0
    • N
      ftrace/instances: Clear function triggers when removing instances · a0e6369e
      Naveen N. Rao 提交于
      If instance directories are deleted while there are registered function
      triggers:
      
        # cd /sys/kernel/debug/tracing/instances
        # mkdir test
        # echo "schedule:enable_event:sched:sched_switch" > test/set_ftrace_filter
        # rmdir test
        Unable to handle kernel paging request for data at address 0x00000008
        Unable to handle kernel paging request for data at address 0x00000008
        Faulting instruction address: 0xc0000000021edde8
        Oops: Kernel access of bad area, sig: 11 [#1]
        SMP NR_CPUS=2048
        NUMA
        pSeries
        Modules linked in: iptable_mangle ipt_MASQUERADE nf_nat_masquerade_ipv4 iptable_nat nf_nat_ipv4 nf_nat nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack ipt_REJECT nf_reject_ipv4 xt_tcpudp tun bridge stp llc kvm iptable_filter fuse binfmt_misc pseries_rng rng_core vmx_crypto ib_iser rdma_cm iw_cm ib_cm ib_core libiscsi scsi_transport_iscsi ip_tables x_tables autofs4 btrfs raid10 raid456 async_raid6_recov async_memcpy async_pq async_xor async_tx xor raid6_pq libcrc32c multipath virtio_net virtio_blk virtio_pci crc32c_vpmsum virtio_ring virtio
        CPU: 8 PID: 8694 Comm: rmdir Not tainted 4.11.0-nnr+ #113
        task: c0000000bab52800 task.stack: c0000000baba0000
        NIP: c0000000021edde8 LR: c0000000021f0590 CTR: c000000002119620
        REGS: c0000000baba3870 TRAP: 0300   Not tainted  (4.11.0-nnr+)
        MSR: 8000000000009033 <SF,EE,ME,IR,DR,RI,LE>
          CR: 22002422  XER: 20000000
        CFAR: 00007fffabb725a8 DAR: 0000000000000008 DSISR: 40000000 SOFTE: 0
        GPR00: c00000000220f750 c0000000baba3af0 c000000003157e00 0000000000000000
        GPR04: 0000000000000040 00000000000000eb 0000000000000040 0000000000000000
        GPR08: 0000000000000000 0000000000000113 0000000000000000 c00000000305db98
        GPR12: c000000002119620 c00000000fd42c00 0000000000000000 0000000000000000
        GPR16: 0000000000000000 0000000000000000 0000000000000000 0000000000000000
        GPR20: 0000000000000000 0000000000000000 c0000000bab52e90 0000000000000000
        GPR24: 0000000000000000 00000000000000eb 0000000000000040 c0000000baba3bb0
        GPR28: c00000009cb06eb0 c0000000bab52800 c00000009cb06eb0 c0000000baba3bb0
        NIP [c0000000021edde8] ring_buffer_lock_reserve+0x8/0x4e0
        LR [c0000000021f0590] trace_event_buffer_lock_reserve+0xe0/0x1a0
        Call Trace:
        [c0000000baba3af0] [c0000000021f96c8] trace_event_buffer_commit+0x1b8/0x280 (unreliable)
        [c0000000baba3b60] [c00000000220f750] trace_event_buffer_reserve+0x80/0xd0
        [c0000000baba3b90] [c0000000021196b8] trace_event_raw_event_sched_switch+0x98/0x180
        [c0000000baba3c10] [c0000000029d9980] __schedule+0x6e0/0xab0
        [c0000000baba3ce0] [c000000002122230] do_task_dead+0x70/0xc0
        [c0000000baba3d10] [c0000000020ea9c8] do_exit+0x828/0xd00
        [c0000000baba3dd0] [c0000000020eaf70] do_group_exit+0x60/0x100
        [c0000000baba3e10] [c0000000020eb034] SyS_exit_group+0x24/0x30
        [c0000000baba3e30] [c00000000200bcec] system_call+0x38/0x54
        Instruction dump:
        60000000 60420000 7d244b78 7f63db78 4bffaa09 393efff8 793e0020 39200000
        4bfffecc 60420000 3c4c00f7 3842a020 <81230008> 2f890000 409e02f0 a14d0008
        ---[ end trace b917b8985d0e650b ]---
        Unable to handle kernel paging request for data at address 0x00000008
        Faulting instruction address: 0xc0000000021edde8
        Unable to handle kernel paging request for data at address 0x00000008
        Faulting instruction address: 0xc0000000021edde8
        Faulting instruction address: 0xc0000000021edde8
      
      To address this, let's clear all registered function probes before
      deleting the ftrace instance.
      
      Link: http://lkml.kernel.org/r/c5f1ca624043690bd94642bb6bffd3f2fc504035.1494956770.git.naveen.n.rao@linux.vnet.ibm.comReported-by: NMichael Ellerman <mpe@ellerman.id.au>
      Signed-off-by: NNaveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      a0e6369e
    • S
      tracing: Move postpone selftests to core from early_initcall · b9ef0326
      Steven Rostedt 提交于
      I hit the following lockdep splat when booting with ftrace selftests
      enabled, as well as CONFIG_PREEMPT and LOCKDEP.
      
       Testing dynamic ftrace ops #1:
       (1 0 1 0 0)
       (1 1 2 0 0)
       (2 1 3 0 169)
       (2 2 4 0 50066)
       ------------[ cut here ]------------
       WARNING: CPU: 0 PID: 13 at kernel/rcu/srcutree.c:202 check_init_srcu_struct+0x60/0x70
       Modules linked in:
       CPU: 0 PID: 13 Comm: rcu_tasks_kthre Not tainted 4.12.0-rc1-test+ #587
       Hardware name: Hewlett-Packard HP Compaq Pro 6300 SFF/339A, BIOS K01 v02.05 05/07/2012
       task: ffff880119628040 task.stack: ffffc900006a4000
       RIP: 0010:check_init_srcu_struct+0x60/0x70
       RSP: 0000:ffffc900006a7d98 EFLAGS: 00010246
       RAX: 0000000000000246 RBX: 0000000000000000 RCX: 0000000000000000
       RDX: ffff880119628040 RSI: 00000000ffffffff RDI: ffffffff81e5fb40
       RBP: ffffc900006a7e20 R08: 00000023b403c000 R09: 0000000000000001
       R10: ffffc900006a7e40 R11: 0000000000000000 R12: ffffffff81e5fb40
       R13: 0000000000000286 R14: ffff880119628040 R15: ffffc900006a7e98
       FS:  0000000000000000(0000) GS:ffff88011ea00000(0000) knlGS:0000000000000000
       CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
       CR2: ffff88011edff000 CR3: 0000000001e0f000 CR4: 00000000001406f0
       Call Trace:
        ? __synchronize_srcu+0x6e/0x140
        ? lock_acquire+0xdc/0x1d0
        ? ktime_get_mono_fast_ns+0x5d/0xb0
        synchronize_srcu+0x6f/0x110
        ? synchronize_srcu+0x6f/0x110
        rcu_tasks_kthread+0x20a/0x540
        kthread+0x114/0x150
        ? __rcu_read_unlock+0x70/0x70
        ? kthread_create_on_node+0x40/0x40
        ret_from_fork+0x2e/0x40
       Code: f6 83 70 06 00 00 03 49 89 c5 74 0d be 01 00 00 00 48 89 df e8 42 fa ff ff 4c 89 ee 4c 89 e7 e8 b7 42 75 00 5b 41 5c 41 5d 5d c3 <0f> ff eb aa 66 90 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
       ---[ end trace 5c3f4206ce50f6ac ]---
      
      What happens is that the selftests include a creating of a dynamically
      allocated ftrace_ops, which requires the use of synchronize_rcu_tasks()
      which uses srcu, and triggers the above warning.
      
      It appears that synchronize_rcu_tasks() is not set up at early_initcall(),
      but it is at core_initcall(). By moving the tests down to that location
      works out properly.
      
      Link: http://lkml.kernel.org/r/20170517111435.7388c033@gandalf.local.homeAcked-by: N"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      b9ef0326
  13. 09 5月, 2017 1 次提交
  14. 04 5月, 2017 1 次提交
  15. 01 5月, 2017 1 次提交
    • S
      ring-buffer: Return reader page back into existing ring buffer · 73a757e6
      Steven Rostedt (VMware) 提交于
      When reading the ring buffer for consuming, it is optimized for splice,
      where a page is taken out of the ring buffer (zero copy) and sent to the
      reading consumer. When the read is finished with the page, it calls
      ring_buffer_free_read_page(), which simply frees the page. The next time the
      reader needs to get a page from the ring buffer, it must call
      ring_buffer_alloc_read_page() which allocates and initializes a reader page
      for the ring buffer to be swapped into the ring buffer for a new filled page
      for the reader.
      
      The problem is that there's no reason to actually free the page when it is
      passed back to the ring buffer. It can hold it off and reuse it for the next
      iteration. This completely removes the interaction with the page_alloc
      mechanism.
      
      Using the trace-cmd utility to record all events (causing trace-cmd to
      require reading lots of pages from the ring buffer, and calling
      ring_buffer_alloc/free_read_page() several times), and also assigning a
      stack trace trigger to the mm_page_alloc event, we can see how many times
      the ring_buffer_alloc_read_page() needed to allocate a page for the ring
      buffer.
      
      Before this change:
      
        # trace-cmd record -e all -e mem_page_alloc -R stacktrace sleep 1
        # trace-cmd report |grep ring_buffer_alloc_read_page | wc -l
        9968
      
      After this change:
      
        # trace-cmd record -e all -e mem_page_alloc -R stacktrace sleep 1
        # trace-cmd report |grep ring_buffer_alloc_read_page | wc -l
        4
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      73a757e6
  16. 21 4月, 2017 10 次提交
    • S
      tracing/ftrace: Allow for the traceonoff probe be unique to instances · 2290f2c5
      Steven Rostedt (VMware) 提交于
      Have the traceon/off function probe triggers affect only the instance they
      are set in. This required making the trace_on/off accessible for other files
      in the tracing directory.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      2290f2c5
    • S
      tracing/ftrace: Enable snapshot function trigger to work with instances · cab50379
      Steven Rostedt (VMware) 提交于
      Modify the snapshot probe trigger to work with instances. This way the
      snapshot function trigger will only affect the instance that it is added to
      in the set_ftrace_filter file.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      cab50379
    • S
      tracing/ftrace: Add a better way to pass data via the probe functions · 6e444319
      Steven Rostedt (VMware) 提交于
      With the redesign of the registration and execution of the function probes
      (triggers), data can now be passed from the setup of the probe to the probe
      callers that are specific to the trace_array it is on. Although, all probes
      still only affect the toplevel trace array, this change will allow for
      instances to have their own probes separated from other instances and the
      top array.
      
      That is, something like the stacktrace probe can be set to trace only in an
      instance and not the toplevel trace array. This isn't implement yet, but
      this change sets the ground work for the change.
      
      When a probe callback is triggered (someone writes the probe format into
      set_ftrace_filter), it calls register_ftrace_function_probe() passing in
      init_data that will be used to initialize the probe. Then for every matching
      function, register_ftrace_function_probe() will call the probe_ops->init()
      function with the init data that was passed to it, as well as an address to
      a place holder that is associated with the probe and the instance. The first
      occurrence will have a NULL in the pointer. The init() function will then
      initialize it. If other probes are added, or more functions are part of the
      probe, the place holder will be passed to the init() function with the place
      holder data that it was initialized to the last time.
      
      Then this place_holder is passed to each of the other probe_ops functions,
      where it can be used in the function callback. When the probe_ops free()
      function is called, it can be called either with the rip of the function
      that is being removed from the probe, or zero, indicating that there are no
      more functions attached to the probe, and the place holder is about to be
      freed. This gives the probe_ops a way to free the data it assigned to the
      place holder if it was allocade during the first init call.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      6e444319
    • S
      ftrace: Dynamically create the probe ftrace_ops for the trace_array · 7b60f3d8
      Steven Rostedt (VMware) 提交于
      In order to eventually have each trace_array instance have its own unique
      set of function probes (triggers), the trace array needs to hold the ops and
      the filters for the probes.
      
      This is the first step to accomplish this. Instead of having the private
      data of the probe ops point to the trace_array, create a separate list that
      the trace_array holds. There's only one private_data for a probe, we need
      one per trace_array. The probe ftrace_ops will be dynamically created for
      each instance, instead of being static.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      7b60f3d8
    • S
      tracing: Pass the trace_array into ftrace_probe_ops functions · b5f081b5
      Steven Rostedt (VMware) 提交于
      Pass the trace_array associated to a ftrace_probe_ops into the probe_ops
      func(), init() and free() functions. The trace_array is the descriptor that
      describes a tracing instance. This will help create the infrastructure that
      will allow having function probes unique to tracing instances.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      b5f081b5
    • S
      tracing: Have the trace_array hold the list of registered func probes · 04ec7bb6
      Steven Rostedt (VMware) 提交于
      Add a link list to the trace_array to hold func probes that are registered.
      Currently, all function probes are the same for all instances as it was
      before, that is, only the top level trace_array holds the function probes.
      But this lays the ground work to have function probes be attached to
      individual instances, and having the event trigger only affect events in the
      given instance. But that work is still to be done.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      04ec7bb6
    • S
      ftrace: Have unregister_ftrace_function_probe_func() return a value · d3d532d7
      Steven Rostedt (VMware) 提交于
      Currently unregister_ftrace_function_probe_func() is a void function. It
      does not give any feedback if an error occurred or no item was found to
      remove and nothing was done.
      
      Change it to return status and success if it removed something. Also update
      the callers to return that feedback to the user.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      d3d532d7
    • S
      ftrace: Remove data field from ftrace_func_probe structure · 1a48df00
      Steven Rostedt (VMware) 提交于
      No users of the function probes uses the data field anymore. Remove it, and
      change the init function to take a void *data parameter instead of a
      void **data, because the init will just get the data that the registering
      function was received, and there's no state after it is called.
      
      The other functions for ftrace_probe_ops still take the data parameter, but
      it will currently only be passed NULL. It will stay as a parameter for
      future data to be passed to these functions.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      1a48df00
    • S
      tracing: Have the snapshot trigger use the mapping helper functions · 1a93f8bd
      Steven Rostedt (VMware) 提交于
      As the data pointer for individual ips will soon be removed and no longer
      passed to the callback function probe handlers, convert the snapshot
      trigger counter over to the new ftrace_func_mapper helper functions.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      1a93f8bd
    • S
      ftrace: Pass probe ops to probe function · bca6c8d0
      Steven Rostedt (VMware) 提交于
      In preparation to cleaning up the probe function registration code, the
      "data" parameter will eventually be removed from the probe->func() call.
      Instead it will receive its own "ops" function, in which it can set up its
      own data that it needs to map.
      Signed-off-by: NSteven Rostedt (VMware) <rostedt@goodmis.org>
      bca6c8d0