linux/drivers/oprofile/cpu_buffer.c, branch v5.11

tracing: Make struct ring_buffer less ambiguous

2020-01-13T18:19:38Z

As there's two struct ring_buffers in the kernel, it causes some confusion. The other one being the perf ring buffer. It was agreed upon that as neither of the ring buffers are generic enough to be used globally, they should be renamed as: perf's ring_buffer -> perf_buffer ftrace's ring_buffer -> trace_buffer This implements the changes to the ring buffer that ftrace uses. Link: https://lore.kernel.org/r/20191213140531.116b3200@gandalf.local.home Signed-off-by: Steven Rostedt (VMware)

sched/headers: Prepare for the removal of from

2017-03-02T07:42:31Z

Fix up missing #includes in other places that rely on sched.h doing that for them. Acked-by: Linus Torvalds Cc: Mike Galbraith Cc: Peter Zijlstra Cc: Thomas Gleixner Cc: linux-kernel@vger.kernel.org Signed-off-by: Ingo Molnar

drivers/oprofile: Replace __get_cpu_var uses for address calculation

2014-08-26T17:45:46Z

Replace the uses of __get_cpu_var for address calculation with this_cpu_ptr. Cc: Robert Richter Cc: oprofile-list@lists.sf.net Signed-off-by: Christoph Lameter Signed-off-by: Tejun Heo

oprofile: Remove 'WQ on CPUx, prefer CPUy' warning

2012-08-27T12:49:39Z

Under certain workloads we see the following warnings: WQ on CPU0, prefer CPU1 WQ on CPU0, prefer CPU2 WQ on CPU0, prefer CPU3 It warns the user that the wq to access a per-cpu buffers runs not on the same cpu. This happens if the wq is rescheduled on a different cpu than where the buffer is located. This was probably implemented to detect performance issues. Not sure if there actually is one as the buffers are copied to a single buffer anyway which should be the actual bottleneck. We wont change WQ implementation. Since a user can do nothing the warning is pointless. Removing it. Cc: Andi Kleen Signed-off-by: Robert Richter

oprofile: Introduce new oprofile sample add function (oprofile_add_ext_hw_sample)

2011-02-15T10:07:07Z

This patch introduces a new oprofile sample add function (oprofile_add_ext_hw_sample) that can also take task_struct as an argument, which is used by the hwsampler kernel module when copying hardware samples to OProfile buffers. Applied with following changes: * removed #include * whitespace changes * removed conditional compilation (CONFIG_HAVE_HWSAMPLER) * modified order of functions * fix missing function definition in header file Signed-off-by: Mahesh Salgaonkar Signed-off-by: Maran Pakkirisamy Signed-off-by: Heinz Graalfs Acked-by: Heiko Carstens Signed-off-by: Robert Richter

oprofile: Remove deprecated use of flush_scheduled_work()

2010-10-29T09:54:18Z

flush_scheduled_work() is deprecated and scheduled to be removed. sync_stop() currently cancels cpu_buffer works inside buffer_mutex and flushes the system workqueue outside. Instead, split end_cpu_work() into two parts - stopping further work enqueues and flushing works - and do the former inside buffer_mutex and latter outside. For stable kernels v2.6.35.y and v2.6.36.y. Signed-off-by: Tejun Heo Cc: stable@kernel.org Signed-off-by: Robert Richter

oprofile: fix crash when accessing freed task structs

2010-08-25T07:09:09Z

This patch fixes a crash during shutdown reported below. The crash is caused by accessing already freed task structs. The fix changes the order for registering and unregistering notifier callbacks. All notifiers must be initialized before buffers start working. To stop buffer synchronization we cancel all workqueues, unregister the notifier callback and then flush all buffers. After all of this we finally can free all tasks listed. This should avoid accessing freed tasks. On 22.07.10 01:14:40, Benjamin Herrenschmidt wrote: > So the initial observation is a spinlock bad magic followed by a crash > in the spinlock debug code: > > [ 1541.586531] BUG: spinlock bad magic on CPU#5, events/5/136 > [ 1541.597564] Unable to handle kernel paging request for data at address 0x6b6b6b6b6b6b6d03 > > Backtrace looks like: > > spin_bug+0x74/0xd4 > ._raw_spin_lock+0x48/0x184 > ._spin_lock+0x10/0x24 > .get_task_mm+0x28/0x8c > .sync_buffer+0x1b4/0x598 > .wq_sync_buffer+0xa0/0xdc > .worker_thread+0x1d8/0x2a8 > .kthread+0xa8/0xb4 > .kernel_thread+0x54/0x70 > > So we are accessing a freed task struct in the work queue when > processing the samples. Reported-by: Benjamin Herrenschmidt Cc: stable@kernel.org Signed-off-by: Robert Richter

oprofile: protect from not being in an IRQ context

2010-05-03T21:02:39Z

http://lkml.org/lkml/2010/4/27/285 Protect against dereferencing regs when it's NULL, and force a magic number into pc to prevent too deep processing. This approach permits the dropped samples to be tallied as invalid Instruction Pointer events. e.g. output from about 15mins at 10kHz sample rate: Nr. samples received: 2565380 Nr. samples lost invalid pc: 4 Signed-off-by: Phil Carmody Signed-off-by: Robert Richter

Merge commit 'tip/tracing/core' into oprofile/core

2010-04-23T14:47:51Z

Conflicts: drivers/oprofile/cpu_buffer.c Signed-off-by: Robert Richter

oprofile: remove double ring buffering

2010-04-23T13:30:38Z

oprofile used a double buffer scheme for its cpu event buffer to avoid races on reading with the old locked ring buffer. But that is obsolete now with the new ring buffer, so simply use a single buffer. This greatly simplifies the code and avoids a lot of sample drops on large runs, especially with call graph. Based on suggestions from Steven Rostedt For stable kernels from v2.6.32, but not earlier. Signed-off-by: Andi Kleen Cc: Steven Rostedt Cc: stable Signed-off-by: Robert Richter