All of lore.kernel.org
 help / color / mirror / Atom feed
* 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.