* perf/workqueue: lockdep warning on process exit
@ 2014-06-16 14:24 Sasha Levin
2014-06-16 21:41 ` Sasha Levin
` (2 more replies)
0 siblings, 3 replies; 7+ messages in thread
From: Sasha Levin @ 2014-06-16 14:24 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, acme, paulus, Tejun Heo; +Cc: LKML, Dave Jones
Hi all,
While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel I've stumbled on the following spew:
[ 430.429005] ======================================================
[ 430.429005] [ INFO: possible circular locking dependency detected ]
[ 430.429005] 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654 Not tainted
[ 430.429005] -------------------------------------------------------
[ 430.429005] trinity-c578/9725 is trying to acquire lock:
[ 430.429005] (&(&pool->lock)->rlock){-.-...}, at: __queue_work (kernel/workqueue.c:1346)
[ 430.429005]
[ 430.429005] but task is already holding lock:
[ 430.429005] (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
[ 430.439509]
[ 430.439509] which lock already depends on the new lock.
[ 430.439509]
[ 430.439509]
[ 430.439509] the existing dependency chain (in reverse order) is:
[ 430.439509]
-> #3 (&ctx->lock){-.....}:
[ 430.439509] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 430.439509] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
[ 430.439509] __perf_event_task_sched_out (kernel/events/core.c:2358 kernel/events/core.c:2384)
[ 430.450111] perf_event_task_sched_out (include/linux/perf_event.h:702)
[ 430.450111] __schedule (kernel/sched/core.c:2138 kernel/sched/core.c:2176 kernel/sched/core.c:2300 kernel/sched/core.c:2795)
[ 430.450111] preempt_schedule_irq (./arch/x86/include/asm/paravirt.h:814 kernel/sched/core.c:2912)
[ 430.450111] retint_kernel (arch/x86/kernel/entry_64.S:936)
[ 430.450111] syscall_trace_leave (arch/x86/kernel/ptrace.c:1531)
[ 430.450111] int_check_syscall_exit_work (arch/x86/kernel/entry_64.S:590)
[ 430.450111]
-> #2 (&rq->lock){-.-.-.}:
[ 430.450111] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 430.450111] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
[ 430.450111] wake_up_new_task (include/linux/sched.h:2889 kernel/sched/core.c:329 kernel/sched/core.c:2088)
[ 430.450111] do_fork (kernel/fork.c:1628)
[ 430.450111] kernel_thread (kernel/fork.c:1650)
[ 430.450111] rest_init (init/main.c:405)
[ 430.450111] start_kernel (init/main.c:680)
[ 430.450111] x86_64_start_reservations (arch/x86/kernel/head64.c:194)
[ 430.450111] x86_64_start_kernel (arch/x86/kernel/head64.c:183)
[ 430.450111]
-> #1 (&p->pi_lock){-.-.-.}:
[ 430.450111] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 430.450111] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:117 kernel/locking/spinlock.c:159)
[ 430.450111] try_to_wake_up (kernel/sched/core.c:1666)
[ 430.450111] wake_up_process (kernel/sched/core.c:1762 (discriminator 2))
[ 430.450111] create_and_start_worker (include/linux/spinlock.h:353 kernel/workqueue.c:1768)
[ 430.450111] init_workqueues (kernel/workqueue.c:4938)
[ 430.450111] do_one_initcall (init/main.c:790)
[ 430.450111] kernel_init_freeable (init/main.c:891 init/main.c:998)
[ 430.450111] kernel_init (init/main.c:936)
[ 430.450111] ret_from_fork (arch/x86/kernel/entry_64.S:349)
[ 430.450111]
-> #0 (&(&pool->lock)->rlock){-.-...}:
[ 430.450111] __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182)
[ 430.450111] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 430.450111] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
[ 430.450111] __queue_work (kernel/workqueue.c:1346)
[ 430.450111] queue_work_on (kernel/workqueue.c:1424)
[ 430.450111] free_object (lib/debugobjects.c:209)
[ 430.450111] __debug_check_no_obj_freed (lib/debugobjects.c:715)
[ 430.450111] debug_check_no_obj_freed (lib/debugobjects.c:727)
[ 430.450111] kmem_cache_free (mm/slub.c:2683 mm/slub.c:2711)
[ 430.450111] free_task (kernel/fork.c:221)
[ 430.450111] __put_task_struct (kernel/fork.c:250)
[ 430.450111] put_ctx (include/linux/sched.h:1855 kernel/events/core.c:898)
[ 430.450111] perf_event_exit_task (kernel/events/core.c:907 kernel/events/core.c:7478 kernel/events/core.c:7533)
[ 430.450111] do_exit (kernel/exit.c:766)
[ 430.450111] do_group_exit (kernel/exit.c:884)
[ 430.450111] get_signal_to_deliver (kernel/signal.c:2347)
[ 430.450111] do_signal (arch/x86/kernel/signal.c:698)
[ 430.450111] do_notify_resume (arch/x86/kernel/signal.c:751)
[ 430.450111] int_signal (arch/x86/kernel/entry_64.S:600)
[ 430.450111]
[ 430.450111] other info that might help us debug this:
[ 430.450111]
[ 430.450111] Chain exists of:
&(&pool->lock)->rlock --> &rq->lock --> &ctx->lock
[ 430.450111] Possible unsafe locking scenario:
[ 430.450111]
[ 430.450111] CPU0 CPU1
[ 430.450111] ---- ----
[ 430.450111] lock(&ctx->lock);
[ 430.450111] lock(&rq->lock);
[ 430.450111] lock(&ctx->lock);
[ 430.450111] lock(&(&pool->lock)->rlock);
[ 430.450111]
[ 430.450111] *** DEADLOCK ***
[ 430.450111]
[ 430.450111] 1 lock held by trinity-c578/9725:
[ 430.450111] #0: (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
[ 430.450111]
[ 430.450111] stack backtrace:
[ 430.450111] CPU: 6 PID: 9725 Comm: trinity-c578 Not tainted 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654
[ 430.450111] ffffffffadb45840 ffff880101787848 ffffffffaa511b1c 0000000000000003
[ 430.450111] ffffffffadb8a4c0 ffff880101787898 ffffffffaa5044e2 0000000000000001
[ 430.450111] ffff880101787928 ffff880101787898 ffff8800aed98cf8 ffff8800aed98000
[ 430.450111] Call Trace:
[ 430.450111] dump_stack (lib/dump_stack.c:52)
[ 430.450111] print_circular_bug (kernel/locking/lockdep.c:1216)
[ 430.450111] __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182)
[ 430.450111] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
[ 430.450111] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
[ 430.450111] ? put_lock_stats.isra.12 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
[ 430.450111] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 430.450111] ? __queue_work (kernel/workqueue.c:1346)
[ 430.450111] ? __lock_is_held (kernel/locking/lockdep.c:3516)
[ 430.450111] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
[ 430.450111] ? __queue_work (kernel/workqueue.c:1346)
[ 430.450111] __queue_work (kernel/workqueue.c:1346)
[ 430.450111] queue_work_on (kernel/workqueue.c:1424)
[ 430.450111] free_object (lib/debugobjects.c:209)
[ 430.450111] __debug_check_no_obj_freed (lib/debugobjects.c:715)
[ 430.450111] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 430.450111] debug_check_no_obj_freed (lib/debugobjects.c:727)
[ 430.450111] kmem_cache_free (mm/slub.c:2683 mm/slub.c:2711)
[ 430.450111] ? free_task (kernel/fork.c:221)
[ 430.450111] free_task (kernel/fork.c:221)
[ 430.450111] __put_task_struct (kernel/fork.c:250)
[ 430.450111] put_ctx (include/linux/sched.h:1855 kernel/events/core.c:898)
[ 430.450111] perf_event_exit_task (kernel/events/core.c:907 kernel/events/core.c:7478 kernel/events/core.c:7533)
[ 430.450111] ? preempt_count_sub (kernel/sched/core.c:2602)
[ 430.450111] do_exit (kernel/exit.c:766)
[ 430.450111] ? debug_smp_processor_id (lib/smp_processor_id.c:57)
[ 430.450111] ? put_lock_stats.isra.12 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
[ 430.450111] ? _raw_spin_unlock_irq (./arch/x86/include/asm/paravirt.h:819 include/linux/spinlock_api_smp.h:168 kernel/locking/spinlock.c:199)
[ 430.450111] do_group_exit (kernel/exit.c:884)
[ 430.450111] get_signal_to_deliver (kernel/signal.c:2347)
[ 430.450111] ? vtime_account_user (kernel/sched/cputime.c:687)
[ 430.450111] do_signal (arch/x86/kernel/signal.c:698)
[ 430.450111] ? vtime_account_user (kernel/sched/cputime.c:687)
[ 430.450111] ? preempt_count_sub (kernel/sched/core.c:2602)
[ 430.450111] ? context_tracking_user_exit (./arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:182 (discriminator 2))
[ 430.450111] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 430.450111] ? trace_hardirqs_on_caller (kernel/locking/lockdep.c:2557 kernel/locking/lockdep.c:2599)
[ 430.450111] do_notify_resume (arch/x86/kernel/signal.c:751)
[ 430.450111] int_signal (arch/x86/kernel/entry_64.S:600)
Thanks,
Sasha
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/workqueue: lockdep warning on process exit
2014-06-16 14:24 perf/workqueue: lockdep warning on process exit Sasha Levin
@ 2014-06-16 21:41 ` Sasha Levin
2014-06-17 15:57 ` Tejun Heo
2014-06-23 14:12 ` Peter Zijlstra
2 siblings, 0 replies; 7+ messages in thread
From: Sasha Levin @ 2014-06-16 21:41 UTC (permalink / raw)
To: Peter Zijlstra, Ingo Molnar, acme, paulus, Tejun Heo; +Cc: LKML, Dave Jones
On 06/16/2014 10:24 AM, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
I think that this is due to a recent change, since it seems to reproduce very
often. I've tried bisecting it but it seems that I'm hitting unrelated issues
and can't correctly run the bisection.
Thanks,
Sasha
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/workqueue: lockdep warning on process exit
2014-06-16 14:24 perf/workqueue: lockdep warning on process exit Sasha Levin
2014-06-16 21:41 ` Sasha Levin
@ 2014-06-17 15:57 ` Tejun Heo
2014-06-23 14:12 ` Peter Zijlstra
2 siblings, 0 replies; 7+ messages in thread
From: Tejun Heo @ 2014-06-17 15:57 UTC (permalink / raw)
To: Sasha Levin; +Cc: Peter Zijlstra, Ingo Molnar, acme, paulus, LKML, Dave Jones
Hello,
On Mon, Jun 16, 2014 at 10:24:58AM -0400, Sasha Levin wrote:
> [ 430.429005] ======================================================
> [ 430.429005] [ INFO: possible circular locking dependency detected ]
> [ 430.429005] 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654 Not tainted
> [ 430.429005] -------------------------------------------------------
> [ 430.429005] trinity-c578/9725 is trying to acquire lock:
> [ 430.429005] (&(&pool->lock)->rlock){-.-...}, at: __queue_work (kernel/workqueue.c:1346)
> [ 430.429005]
> [ 430.429005] but task is already holding lock:
> [ 430.429005] (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
> [ 430.439509]
> [ 430.439509] which lock already depends on the new lock.
> [ 430.439509]
> [ 430.439509]
> [ 430.439509] the existing dependency chain (in reverse order) is:
> [ 430.439509]
> -> #3 (&ctx->lock){-.....}:
...
> -> #2 (&rq->lock){-.-.-.}:
...
> -> #1 (&p->pi_lock){-.-.-.}:
...
> -> #0 (&(&pool->lock)->rlock){-.-...}:
...
> [ 430.450111] other info that might help us debug this:
> [ 430.450111]
> [ 430.450111] Chain exists of:
> &(&pool->lock)->rlock --> &rq->lock --> &ctx->lock
>
> [ 430.450111] Possible unsafe locking scenario:
> [ 430.450111]
> [ 430.450111] CPU0 CPU1
> [ 430.450111] ---- ----
> [ 430.450111] lock(&ctx->lock);
> [ 430.450111] lock(&rq->lock);
> [ 430.450111] lock(&ctx->lock);
> [ 430.450111] lock(&(&pool->lock)->rlock);
> [ 430.450111]
> [ 430.450111] *** DEADLOCK ***
> [ 430.450111]
> [ 430.450111] 1 lock held by trinity-c578/9725:
> [ 430.450111] #0: (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
> [ 430.450111]
> [ 430.450111] stack backtrace:
> [ 430.450111] CPU: 6 PID: 9725 Comm: trinity-c578 Not tainted 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654
> [ 430.450111] ffffffffadb45840 ffff880101787848 ffffffffaa511b1c 0000000000000003
> [ 430.450111] ffffffffadb8a4c0 ffff880101787898 ffffffffaa5044e2 0000000000000001
> [ 430.450111] ffff880101787928 ffff880101787898 ffff8800aed98cf8 ffff8800aed98000
> [ 430.450111] Call Trace:
> [ 430.450111] dump_stack (lib/dump_stack.c:52)
> [ 430.450111] print_circular_bug (kernel/locking/lockdep.c:1216)
> [ 430.450111] __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182)
> [ 430.450111] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
> [ 430.450111] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
> [ 430.450111] __queue_work (kernel/workqueue.c:1346)
> [ 430.450111] queue_work_on (kernel/workqueue.c:1424)
> [ 430.450111] free_object (lib/debugobjects.c:209)
> [ 430.450111] __debug_check_no_obj_freed (lib/debugobjects.c:715)
> [ 430.450111] debug_check_no_obj_freed (lib/debugobjects.c:727)
> [ 430.450111] kmem_cache_free (mm/slub.c:2683 mm/slub.c:2711)
> [ 430.450111] free_task (kernel/fork.c:221)
> [ 430.450111] __put_task_struct (kernel/fork.c:250)
> [ 430.450111] put_ctx (include/linux/sched.h:1855 kernel/events/core.c:898)
> [ 430.450111] perf_event_exit_task (kernel/events/core.c:907 kernel/events/core.c:7478 kernel/events/core.c:7533)
> [ 430.450111] do_exit (kernel/exit.c:766)
So, perf_event_exit_task() ends up freeing perf_events under
perf_event_context->lock which may nest inside rq lock. With
SLAB_DEBUG_OBJECTS enabled, sl?b calls into debugobjects which in turn
call into workqueue for its internal management. This leads to
possible deadlock as workqueue is now being invoked under a lock which
nests under rq lock.
This is a really low level feature invoking high level debugging
facility leading to possible deadlocks. I don't know why it showed up
now and there may be better ways but the default thing to do seems to
be turning off SLAB_DEBUG_OBJECTS for perf_events.
Thanks.
--
tejun
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/workqueue: lockdep warning on process exit
2014-06-16 14:24 perf/workqueue: lockdep warning on process exit Sasha Levin
2014-06-16 21:41 ` Sasha Levin
2014-06-17 15:57 ` Tejun Heo
@ 2014-06-23 14:12 ` Peter Zijlstra
2014-06-25 21:17 ` Sasha Levin
2014-07-16 19:19 ` [tip:perf/urgent] perf: Fix " tip-bot for Peter Zijlstra
2 siblings, 2 replies; 7+ messages in thread
From: Peter Zijlstra @ 2014-06-23 14:12 UTC (permalink / raw)
To: Sasha Levin; +Cc: Ingo Molnar, acme, paulus, Tejun Heo, LKML, Dave Jones
On Mon, Jun 16, 2014 at 10:24:58AM -0400, Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
>
> [ 430.429005] ======================================================
> [ 430.429005] [ INFO: possible circular locking dependency detected ]
> [ 430.429005] 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654 Not tainted
> [ 430.429005] -------------------------------------------------------
> [ 430.429005] trinity-c578/9725 is trying to acquire lock:
> [ 430.429005] (&(&pool->lock)->rlock){-.-...}, at: __queue_work (kernel/workqueue.c:1346)
> [ 430.429005]
> [ 430.429005] but task is already holding lock:
> [ 430.429005] (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
> [ 430.439509]
> [ 430.439509] which lock already depends on the new lock.
> [ 430.450111] 1 lock held by trinity-c578/9725:
> [ 430.450111] #0: (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
> [ 430.450111]
> [ 430.450111] stack backtrace:
> [ 430.450111] CPU: 6 PID: 9725 Comm: trinity-c578 Not tainted 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654
> [ 430.450111] ffffffffadb45840 ffff880101787848 ffffffffaa511b1c 0000000000000003
> [ 430.450111] ffffffffadb8a4c0 ffff880101787898 ffffffffaa5044e2 0000000000000001
> [ 430.450111] ffff880101787928 ffff880101787898 ffff8800aed98cf8 ffff8800aed98000
> [ 430.450111] Call Trace:
> [ 430.450111] dump_stack (lib/dump_stack.c:52)
> [ 430.450111] print_circular_bug (kernel/locking/lockdep.c:1216)
> [ 430.450111] __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182)
> [ 430.450111] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
> [ 430.450111] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
> [ 430.450111] __queue_work (kernel/workqueue.c:1346)
> [ 430.450111] queue_work_on (kernel/workqueue.c:1424)
> [ 430.450111] free_object (lib/debugobjects.c:209)
> [ 430.450111] __debug_check_no_obj_freed (lib/debugobjects.c:715)
> [ 430.450111] debug_check_no_obj_freed (lib/debugobjects.c:727)
> [ 430.450111] kmem_cache_free (mm/slub.c:2683 mm/slub.c:2711)
> [ 430.450111] free_task (kernel/fork.c:221)
> [ 430.450111] __put_task_struct (kernel/fork.c:250)
> [ 430.450111] put_ctx (include/linux/sched.h:1855 kernel/events/core.c:898)
> [ 430.450111] perf_event_exit_task (kernel/events/core.c:907 kernel/events/core.c:7478 kernel/events/core.c:7533)
> [ 430.450111] do_exit (kernel/exit.c:766)
> [ 430.450111] do_group_exit (kernel/exit.c:884)
> [ 430.450111] get_signal_to_deliver (kernel/signal.c:2347)
> [ 430.450111] do_signal (arch/x86/kernel/signal.c:698)
> [ 430.450111] do_notify_resume (arch/x86/kernel/signal.c:751)
> [ 430.450111] int_signal (arch/x86/kernel/entry_64.S:600)
Urgh.. so the only way I can make that happen is through:
perf_event_exit_task_context()
raw_spin_lock(&child_ctx->lock);
unclone_ctx(child_ctx)
put_ctx(ctx->parent_ctx);
raw_spin_unlock_irqrestore(&child_ctx->lock);
And we can avoid this by doing something like..
I can't immediately see how this changed recently, but given that you
say its easy to reproduce, can you give this a spin?
---
kernel/events/core.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index a33d9a2bcbd7..5e90fa579055 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7474,7 +7474,7 @@ __perf_event_exit_task(struct perf_event *child_event,
static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
{
struct perf_event *child_event, *next;
- struct perf_event_context *child_ctx;
+ struct perf_event_context *child_ctx, *parent_ctx;
unsigned long flags;
if (likely(!child->perf_event_ctxp[ctxn])) {
@@ -7499,6 +7499,15 @@ static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
raw_spin_lock(&child_ctx->lock);
task_ctx_sched_out(child_ctx);
child->perf_event_ctxp[ctxn] = NULL;
+
+ /*
+ * In order to avoid freeing: child_ctx->parent_ctx->task
+ * under perf_event_context::lock, grab another reference.
+ */
+ parent_ctx = child_ctx->parent_ctx;
+ if (parent_ctx)
+ get_ctx(parent_ctx);
+
/*
* If this context is a clone; unclone it so it can't get
* swapped to another process while we're removing all
@@ -7509,6 +7518,13 @@ static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
raw_spin_unlock_irqrestore(&child_ctx->lock, flags);
/*
+ * Now that we no longer hold perf_event_context::lock, drop
+ * our extra child_ctx->parent_ctx reference.
+ */
+ if (parent_ctx)
+ put_ctx(parent_ctx);
+
+ /*
* Report the task dead after unscheduling the events so that we
* won't get any samples after PERF_RECORD_EXIT. We can however still
* get a few PERF_RECORD_READ events.
^ permalink raw reply related [flat|nested] 7+ messages in thread
* Re: perf/workqueue: lockdep warning on process exit
2014-06-23 14:12 ` Peter Zijlstra
@ 2014-06-25 21:17 ` Sasha Levin
2014-07-07 13:45 ` Peter Zijlstra
2014-07-16 19:19 ` [tip:perf/urgent] perf: Fix " tip-bot for Peter Zijlstra
1 sibling, 1 reply; 7+ messages in thread
From: Sasha Levin @ 2014-06-25 21:17 UTC (permalink / raw)
To: Peter Zijlstra; +Cc: Ingo Molnar, acme, paulus, Tejun Heo, LKML, Dave Jones
On 06/23/2014 10:12 AM, Peter Zijlstra wrote:
> On Mon, Jun 16, 2014 at 10:24:58AM -0400, Sasha Levin wrote:
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools guest running the latest -next
>> kernel I've stumbled on the following spew:
>>
>> [ 430.429005] ======================================================
>> [ 430.429005] [ INFO: possible circular locking dependency detected ]
>> [ 430.429005] 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654 Not tainted
>> [ 430.429005] -------------------------------------------------------
>> [ 430.429005] trinity-c578/9725 is trying to acquire lock:
>> [ 430.429005] (&(&pool->lock)->rlock){-.-...}, at: __queue_work (kernel/workqueue.c:1346)
>> [ 430.429005]
>> [ 430.429005] but task is already holding lock:
>> [ 430.429005] (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
>> [ 430.439509]
>> [ 430.439509] which lock already depends on the new lock.
>
>
>> [ 430.450111] 1 lock held by trinity-c578/9725:
>> [ 430.450111] #0: (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
>> [ 430.450111]
>> [ 430.450111] stack backtrace:
>> [ 430.450111] CPU: 6 PID: 9725 Comm: trinity-c578 Not tainted 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654
>> [ 430.450111] ffffffffadb45840 ffff880101787848 ffffffffaa511b1c 0000000000000003
>> [ 430.450111] ffffffffadb8a4c0 ffff880101787898 ffffffffaa5044e2 0000000000000001
>> [ 430.450111] ffff880101787928 ffff880101787898 ffff8800aed98cf8 ffff8800aed98000
>> [ 430.450111] Call Trace:
>> [ 430.450111] dump_stack (lib/dump_stack.c:52)
>> [ 430.450111] print_circular_bug (kernel/locking/lockdep.c:1216)
>> [ 430.450111] __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182)
>> [ 430.450111] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
>> [ 430.450111] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
>> [ 430.450111] __queue_work (kernel/workqueue.c:1346)
>> [ 430.450111] queue_work_on (kernel/workqueue.c:1424)
>> [ 430.450111] free_object (lib/debugobjects.c:209)
>> [ 430.450111] __debug_check_no_obj_freed (lib/debugobjects.c:715)
>> [ 430.450111] debug_check_no_obj_freed (lib/debugobjects.c:727)
>> [ 430.450111] kmem_cache_free (mm/slub.c:2683 mm/slub.c:2711)
>> [ 430.450111] free_task (kernel/fork.c:221)
>> [ 430.450111] __put_task_struct (kernel/fork.c:250)
>> [ 430.450111] put_ctx (include/linux/sched.h:1855 kernel/events/core.c:898)
>> [ 430.450111] perf_event_exit_task (kernel/events/core.c:907 kernel/events/core.c:7478 kernel/events/core.c:7533)
>> [ 430.450111] do_exit (kernel/exit.c:766)
>> [ 430.450111] do_group_exit (kernel/exit.c:884)
>> [ 430.450111] get_signal_to_deliver (kernel/signal.c:2347)
>> [ 430.450111] do_signal (arch/x86/kernel/signal.c:698)
>> [ 430.450111] do_notify_resume (arch/x86/kernel/signal.c:751)
>> [ 430.450111] int_signal (arch/x86/kernel/entry_64.S:600)
>
>
> Urgh.. so the only way I can make that happen is through:
>
> perf_event_exit_task_context()
> raw_spin_lock(&child_ctx->lock);
> unclone_ctx(child_ctx)
> put_ctx(ctx->parent_ctx);
> raw_spin_unlock_irqrestore(&child_ctx->lock);
>
> And we can avoid this by doing something like..
>
> I can't immediately see how this changed recently, but given that you
> say its easy to reproduce, can you give this a spin?
With the patch I've observed the following, which seems to be related.
[ 1853.792414] ======================================================
[ 1853.794073] [ INFO: possible circular locking dependency detected ]
[ 1853.795636] 3.16.0-rc2-next-20140625-sasha-00023-g9bc0cd4-dirty #727 Tainted: G W
[ 1853.797760] -------------------------------------------------------
[ 1853.799353] trinity-c3/29876 is trying to acquire lock:
[ 1853.800172] (&(&pool->lock)->rlock){-.-.-.}, at: __queue_work (kernel/workqueue.c:1339)
[ 1853.800172]
[ 1853.800172] but task is already holding lock:
[ 1853.800172] (&ctx->lock){-.-...}, at: perf_lock_task_context (kernel/events/core.c:983)
[ 1853.800172]
[ 1853.800172] which lock already depends on the new lock.
[ 1853.800172]
[ 1853.800172]
[ 1853.800172] the existing dependency chain (in reverse order) is:
[ 1853.800172]
-> #3 (&ctx->lock){-.-...}:
[ 1853.800172] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 1853.800172] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
[ 1853.816396] __perf_event_task_sched_out (kernel/events/core.c:2359 kernel/events/core.c:2385)
[ 1853.817250] perf_event_task_sched_out (include/linux/perf_event.h:702)
[ 1853.817250] __schedule (kernel/sched/core.c:2142 kernel/sched/core.c:2180 kernel/sched/core.c:2304 kernel/sched/core.c:2799)
[ 1853.817250] schedule (kernel/sched/core.c:2836)
[ 1853.817250] p9_client_rpc (net/9p/client.c:756 (discriminator 9))
[ 1853.817250] p9_client_getattr_dotl (net/9p/client.c:1754)
[ 1853.817250] v9fs_vfs_getattr_dotl (fs/9p/vfs_inode_dotl.c:496)
[ 1853.817250] vfs_getattr_nosec (fs/stat.c:57)
[ 1853.817250] vfs_getattr (fs/stat.c:73)
[ 1853.817250] vfs_fstatat (fs/stat.c:111)
[ 1853.817250] vfs_lstat (fs/stat.c:130)
[ 1853.817250] SYSC_newlstat (fs/stat.c:284)
[ 1853.817250] SyS_newlstat (fs/stat.c:278)
[ 1853.817250] tracesys (arch/x86/kernel/entry_64.S:542)
[ 1853.817250]
-> #2 (&rq->lock){-.-.-.}:
[ 1853.817250] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 1853.817250] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
[ 1853.817250] wake_up_new_task (include/linux/sched.h:2891 kernel/sched/core.c:329 kernel/sched/core.c:2092)
[ 1853.817250] do_fork (kernel/fork.c:1630)
[ 1853.817250] kernel_thread (kernel/fork.c:1652)
[ 1853.817250] rest_init (init/main.c:404)
[ 1853.817250] start_kernel (init/main.c:681)
[ 1853.817250] x86_64_start_reservations (arch/x86/kernel/head64.c:194)
[ 1853.817250] x86_64_start_kernel (arch/x86/kernel/head64.c:183)
[ 1853.817250]
-> #1 (&p->pi_lock){-.-.-.}:
[ 1853.817250] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 1853.817250] _raw_spin_lock_irqsave (include/linux/spinlock_api_smp.h:117 kernel/locking/spinlock.c:159)
[ 1853.817250] try_to_wake_up (kernel/sched/core.c:1670)
[ 1853.817250] wake_up_process (kernel/sched/core.c:1766 (discriminator 2))
[ 1853.817250] create_and_start_worker (include/linux/spinlock.h:353 kernel/workqueue.c:1764)
[ 1853.817250] init_workqueues (kernel/workqueue.c:4923)
[ 1853.817250] do_one_initcall (init/main.c:791)
[ 1853.817250] kernel_init_freeable (init/main.c:892 init/main.c:999)
[ 1853.817250] kernel_init (init/main.c:937)
[ 1853.817250] ret_from_fork (arch/x86/kernel/entry_64.S:349)
[ 1853.817250]
-> #0 (&(&pool->lock)->rlock){-.-.-.}:
[ 1853.817250] __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182)
[ 1853.817250] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 1853.817250] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
[ 1853.817250] __queue_work (kernel/workqueue.c:1339)
[ 1853.817250] queue_work_on (kernel/workqueue.c:1417)
[ 1853.817250] free_object (lib/debugobjects.c:209)
[ 1853.817250] __debug_check_no_obj_freed (lib/debugobjects.c:715)
[ 1853.817250] debug_check_no_obj_freed (lib/debugobjects.c:727)
[ 1853.817250] kmem_cache_free (mm/slub.c:2657 mm/slub.c:2686)
[ 1853.817250] free_task (kernel/fork.c:221)
[ 1853.817250] __put_task_struct (kernel/fork.c:250)
[ 1853.817250] put_ctx (include/linux/sched.h:1857 kernel/events/core.c:899)
[ 1853.817250] find_get_context (kernel/events/core.c:908 kernel/events/core.c:3161)
[ 1853.817250] SYSC_perf_event_open (kernel/events/core.c:7200)
[ 1853.817250] SyS_perf_event_open (kernel/events/core.c:7064)
[ 1853.817250] tracesys (arch/x86/kernel/entry_64.S:542)
[ 1853.817250]
[ 1853.817250] other info that might help us debug this:
[ 1853.817250]
[ 1853.817250] Chain exists of:
&(&pool->lock)->rlock --> &rq->lock --> &ctx->lock
[ 1853.817250] Possible unsafe locking scenario:
[ 1853.817250]
[ 1853.817250] CPU0 CPU1
[ 1853.817250] ---- ----
[ 1853.817250] lock(&ctx->lock);
[ 1853.817250] lock(&rq->lock);
[ 1853.817250] lock(&ctx->lock);
[ 1853.817250] lock(&(&pool->lock)->rlock);
[ 1853.817250]
[ 1853.817250] *** DEADLOCK ***
[ 1853.817250]
[ 1853.817250] 2 locks held by trinity-c3/29876:
[ 1853.817250] #0: ([watchdog] 4141316 iterations. [F:3363768 S:777188 HI:15026]
cpu_hotplug.lock){++++++}, at: get_online_cpus (kernel/cpu.c:90)
[ 1853.924037] #1: (&ctx->lock){-.-...}, at: perf_lock_task_context (kernel/events/core.c:983)
[ 1853.924037]
[ 1853.924037] stack backtrace:
[ 1853.924037] CPU: 3 PID: 29876 Comm: trinity-c3 Tainted: G W 3.16.0-rc2-next-20140625-sasha-00023-g9bc0cd4-dirty #727
[ 1853.924037] ffffffffa1b4a790 ffff880219dcfa28 ffffffff9e524b4b 0000000000000003
[ 1853.924037] ffffffffa1b8f410 ffff880219dcfa78 ffffffff9e5176e0 0000000000000002
[ 1853.924037] ffff880219dcfb08 ffff880219dcfa78 ffff880206b73d40 ffff880206b73000
[ 1853.924037] Call Trace:
[ 1853.924037] dump_stack (lib/dump_stack.c:52)
[ 1853.924037] print_circular_bug (kernel/locking/lockdep.c:1216)
[ 1853.924037] __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182)
[ 1853.924037] ? kvm_clock_read (./arch/x86/include/asm/preempt.h:90 arch/x86/kernel/kvmclock.c:86)
[ 1853.924037] ? sched_clock (./arch/x86/include/asm/paravirt.h:192 arch/x86/kernel/tsc.c:305)
[ 1853.924037] ? put_lock_stats.isra.12 (./arch/x86/include/asm/preempt.h:98 kernel/locking/lockdep.c:254)
[ 1853.924037] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
[ 1853.924037] ? __queue_work (kernel/workqueue.c:1339)
[ 1853.924037] ? __lock_is_held (kernel/locking/lockdep.c:3516)
[ 1853.924037] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
[ 1853.924037] ? __queue_work (kernel/workqueue.c:1339)
[ 1853.924037] __queue_work (kernel/workqueue.c:1339)
[ 1853.924037] queue_work_on (kernel/workqueue.c:1417)
[ 1853.924037] free_object (lib/debugobjects.c:209)
[ 1853.924037] __debug_check_no_obj_freed (lib/debugobjects.c:715)
[ 1853.924037] ? __this_cpu_preempt_check (lib/smp_processor_id.c:63)
[ 1853.924037] ? free_task (kernel/fork.c:221)
[ 1853.924037] debug_check_no_obj_freed (lib/debugobjects.c:727)
[ 1853.924037] kmem_cache_free (mm/slub.c:2657 mm/slub.c:2686)
[ 1853.924037] free_task (kernel/fork.c:221)
[ 1853.924037] __put_task_struct (kernel/fork.c:250)
[ 1853.924037] put_ctx (include/linux/sched.h:1857 kernel/events/core.c:899)
[ 1853.924037] find_get_context (kernel/events/core.c:908 kernel/events/core.c:3161)
[ 1853.924037] SYSC_perf_event_open (kernel/events/core.c:7200)
[ 1853.924037] ? preempt_count_sub (kernel/sched/core.c:2606)
[ 1853.924037] ? context_tracking_user_exit (./arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:184 (discriminator 2))
[ 1853.924037] SyS_perf_event_open (kernel/events/core.c:7064)
Thanks,
Sasha
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: perf/workqueue: lockdep warning on process exit
2014-06-25 21:17 ` Sasha Levin
@ 2014-07-07 13:45 ` Peter Zijlstra
0 siblings, 0 replies; 7+ messages in thread
From: Peter Zijlstra @ 2014-07-07 13:45 UTC (permalink / raw)
To: Sasha Levin; +Cc: Ingo Molnar, acme, paulus, Tejun Heo, LKML, Dave Jones
[-- Attachment #1: Type: text/plain, Size: 1734 bytes --]
On Wed, Jun 25, 2014 at 05:17:48PM -0400, Sasha Levin wrote:
> [ 1853.817250] 2 locks held by trinity-c3/29876:
> [ 1853.817250] #0: cpu_hotplug.lock){++++++}, at: get_online_cpus (kernel/cpu.c:90)
> [ 1853.924037] #1: (&ctx->lock){-.-...}, at: perf_lock_task_context (kernel/events/core.c:983)
> [ 1853.924037]
> [ 1853.924037] Call Trace:
> [ 1853.924037] lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
> [ 1853.924037] _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
> [ 1853.924037] __queue_work (kernel/workqueue.c:1339)
> [ 1853.924037] queue_work_on (kernel/workqueue.c:1417)
> [ 1853.924037] free_object (lib/debugobjects.c:209)
> [ 1853.924037] __debug_check_no_obj_freed (lib/debugobjects.c:715)
> [ 1853.924037] debug_check_no_obj_freed (lib/debugobjects.c:727)
> [ 1853.924037] kmem_cache_free (mm/slub.c:2657 mm/slub.c:2686)
> [ 1853.924037] free_task (kernel/fork.c:221)
> [ 1853.924037] __put_task_struct (kernel/fork.c:250)
> [ 1853.924037] put_ctx (include/linux/sched.h:1857 kernel/events/core.c:899)
> [ 1853.924037] find_get_context (kernel/events/core.c:908 kernel/events/core.c:3161)
> [ 1853.924037] SYSC_perf_event_open (kernel/events/core.c:7200)
> [ 1853.924037] ? preempt_count_sub (kernel/sched/core.c:2606)
> [ 1853.924037] ? context_tracking_user_exit (./arch/x86/include/asm/paravirt.h:809 (discriminator 2) kernel/context_tracking.c:184 (discriminator 2))
> [ 1853.924037] SyS_perf_event_open (kernel/events/core.c:7064)
Egads.. that shouldn't be possible.
The only put_ctx() from find_get_context() is in the !ctx branch, and if
perf_lock_task_context() returns NULL it shouldn't be holding ctx->lock.
Does this reproduce?
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply [flat|nested] 7+ messages in thread
* [tip:perf/urgent] perf: Fix lockdep warning on process exit
2014-06-23 14:12 ` Peter Zijlstra
2014-06-25 21:17 ` Sasha Levin
@ 2014-07-16 19:19 ` tip-bot for Peter Zijlstra
1 sibling, 0 replies; 7+ messages in thread
From: tip-bot for Peter Zijlstra @ 2014-07-16 19:19 UTC (permalink / raw)
To: linux-tip-commits
Cc: linux-kernel, sasha.levin, hpa, mingo, torvalds, peterz, acme,
davej, tj, tglx
Commit-ID: 4a1c0f262f88e2676fda80a6bf80e7dbccae1dcb
Gitweb: http://git.kernel.org/tip/4a1c0f262f88e2676fda80a6bf80e7dbccae1dcb
Author: Peter Zijlstra <peterz@infradead.org>
AuthorDate: Mon, 23 Jun 2014 16:12:42 +0200
Committer: Ingo Molnar <mingo@kernel.org>
CommitDate: Wed, 16 Jul 2014 13:18:42 +0200
perf: Fix lockdep warning on process exit
Sasha Levin reported:
> While fuzzing with trinity inside a KVM tools guest running the latest -next
> kernel I've stumbled on the following spew:
>
> ======================================================
> [ INFO: possible circular locking dependency detected ]
> 3.15.0-next-20140613-sasha-00026-g6dd125d-dirty #654 Not tainted
> -------------------------------------------------------
> trinity-c578/9725 is trying to acquire lock:
> (&(&pool->lock)->rlock){-.-...}, at: __queue_work (kernel/workqueue.c:1346)
>
> but task is already holding lock:
> (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
>
> which lock already depends on the new lock.
> 1 lock held by trinity-c578/9725:
> #0: (&ctx->lock){-.....}, at: perf_event_exit_task (kernel/events/core.c:7471 kernel/events/core.c:7533)
>
> Call Trace:
> dump_stack (lib/dump_stack.c:52)
> print_circular_bug (kernel/locking/lockdep.c:1216)
> __lock_acquire (kernel/locking/lockdep.c:1840 kernel/locking/lockdep.c:1945 kernel/locking/lockdep.c:2131 kernel/locking/lockdep.c:3182)
> lock_acquire (./arch/x86/include/asm/current.h:14 kernel/locking/lockdep.c:3602)
> _raw_spin_lock (include/linux/spinlock_api_smp.h:143 kernel/locking/spinlock.c:151)
> __queue_work (kernel/workqueue.c:1346)
> queue_work_on (kernel/workqueue.c:1424)
> free_object (lib/debugobjects.c:209)
> __debug_check_no_obj_freed (lib/debugobjects.c:715)
> debug_check_no_obj_freed (lib/debugobjects.c:727)
> kmem_cache_free (mm/slub.c:2683 mm/slub.c:2711)
> free_task (kernel/fork.c:221)
> __put_task_struct (kernel/fork.c:250)
> put_ctx (include/linux/sched.h:1855 kernel/events/core.c:898)
> perf_event_exit_task (kernel/events/core.c:907 kernel/events/core.c:7478 kernel/events/core.c:7533)
> do_exit (kernel/exit.c:766)
> do_group_exit (kernel/exit.c:884)
> get_signal_to_deliver (kernel/signal.c:2347)
> do_signal (arch/x86/kernel/signal.c:698)
> do_notify_resume (arch/x86/kernel/signal.c:751)
> int_signal (arch/x86/kernel/entry_64.S:600)
Urgh.. so the only way I can make that happen is through:
perf_event_exit_task_context()
raw_spin_lock(&child_ctx->lock);
unclone_ctx(child_ctx)
put_ctx(ctx->parent_ctx);
raw_spin_unlock_irqrestore(&child_ctx->lock);
And we can avoid this by doing the change below.
I can't immediately see how this changed recently, but given that you
say it's easy to reproduce, lets fix this.
Reported-by: Sasha Levin <sasha.levin@oracle.com>
Signed-off-by: Peter Zijlstra <peterz@infradead.org>
Cc: Tejun Heo <tj@kernel.org>
Cc: Dave Jones <davej@redhat.com>
Cc: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Link: http://lkml.kernel.org/r/20140623141242.GB19860@laptop.programming.kicks-ass.net
Signed-off-by: Ingo Molnar <mingo@kernel.org>
---
kernel/events/core.c | 18 +++++++++++++++++-
1 file changed, 17 insertions(+), 1 deletion(-)
diff --git a/kernel/events/core.c b/kernel/events/core.c
index c46b02b..6b17ac1 100644
--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -7486,7 +7486,7 @@ __perf_event_exit_task(struct perf_event *child_event,
static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
{
struct perf_event *child_event, *next;
- struct perf_event_context *child_ctx;
+ struct perf_event_context *child_ctx, *parent_ctx;
unsigned long flags;
if (likely(!child->perf_event_ctxp[ctxn])) {
@@ -7511,6 +7511,15 @@ static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
raw_spin_lock(&child_ctx->lock);
task_ctx_sched_out(child_ctx);
child->perf_event_ctxp[ctxn] = NULL;
+
+ /*
+ * In order to avoid freeing: child_ctx->parent_ctx->task
+ * under perf_event_context::lock, grab another reference.
+ */
+ parent_ctx = child_ctx->parent_ctx;
+ if (parent_ctx)
+ get_ctx(parent_ctx);
+
/*
* If this context is a clone; unclone it so it can't get
* swapped to another process while we're removing all
@@ -7521,6 +7530,13 @@ static void perf_event_exit_task_context(struct task_struct *child, int ctxn)
raw_spin_unlock_irqrestore(&child_ctx->lock, flags);
/*
+ * Now that we no longer hold perf_event_context::lock, drop
+ * our extra child_ctx->parent_ctx reference.
+ */
+ if (parent_ctx)
+ put_ctx(parent_ctx);
+
+ /*
* Report the task dead after unscheduling the events so that we
* won't get any samples after PERF_RECORD_EXIT. We can however still
* get a few PERF_RECORD_READ events.
^ permalink raw reply related [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-07-16 19:20 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-06-16 14:24 perf/workqueue: lockdep warning on process exit Sasha Levin
2014-06-16 21:41 ` Sasha Levin
2014-06-17 15:57 ` Tejun Heo
2014-06-23 14:12 ` Peter Zijlstra
2014-06-25 21:17 ` Sasha Levin
2014-07-07 13:45 ` Peter Zijlstra
2014-07-16 19:19 ` [tip:perf/urgent] perf: Fix " tip-bot for Peter Zijlstra
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).