oprofile: fix crash when accessing freed task structs
commitf4db115e77b11a8ff22bcd9a3900f03d396a7a53
authorRobert Richter <robert.richter@amd.com>
Fri, 13 Aug 2010 14:29:04 +0000 (13 16:29 +0200)
committerGreg Kroah-Hartman <gregkh@suse.de>
Mon, 20 Sep 2010 20:17:50 +0000 (20 13:17 -0700)
treec5c56208f54fd7dfe3ff06a21cce54c8cc8feb12
parent11bb28b4168d940f156b9752e8d12ca403cb0426
oprofile: fix crash when accessing freed task structs

commit 750d857c682f4db60d14722d430c7ccc35070962 upstream.

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 <benh@kernel.crashing.org>
Signed-off-by: Robert Richter <robert.richter@amd.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
drivers/oprofile/buffer_sync.c
drivers/oprofile/cpu_buffer.c