public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Thomas Gleixner <tglx@linutronix.de>
Cc: Borislav Petkov <bp@alien8.de>,
	Sebastian Andrzej Siewior <bigeasy@linutronix.de>,
	lkml <linux-kernel@vger.kernel.org>
Subject: Re: WARNING: possible circular locking dependency detected
Date: Fri, 1 Sep 2017 22:32:50 +0200	[thread overview]
Message-ID: <20170901203250.GS6524@worktop.programming.kicks-ass.net> (raw)
In-Reply-To: <alpine.DEB.2.20.1708312321410.2346@nanos>

On Thu, Aug 31, 2017 at 11:24:13PM +0200, Thomas Gleixner wrote:
> On Thu, 31 Aug 2017, Thomas Gleixner wrote:
> > On Thu, 31 Aug 2017, Peter Zijlstra wrote:
> > 
> > > On Thu, Aug 31, 2017 at 09:55:57AM +0200, Thomas Gleixner wrote:
> > > > > Arghh!!!
> > > > > 
> > > > > And allowing us to create events for offline CPUs (possible I think, but
> > > > > maybe slightly tricky) won't solve that, because we're already holding
> > > > > the hotplug_lock during PREPARE.
> > > > 
> > > > There are two ways to cure that:
> > > > 
> > > > 1) Have a pre cpus_write_lock() stage which is serialized via
> > > >    cpus_add_remove_lock, which is the outer lock for hotplug.
> > > > 
> > > >    There we can sanely create stuff and fail with all consequences.
> > > 
> > > True, if you're willing to add more state to that hotplug thing I'll try
> > > and make that perf patch that allows attaching to offline CPUs.
> > 
> > Now that I think more about it. That's going to be an interesting exercise
> > vs. the hotplug state registration which relies on cpus_read_lock()
> > serialization.....
> 
> We could have that for built-in stuff which is guaranteed to be never
> unregistered. Pretty restricted, but for cases like that it could
> work. Famous last work ...

I think something like this (on top of the previous patch that preserves
the event<->cpu relation over hotplug) should allow
perf_event_create_kernel_counter() to create events on offline CPUs.

It will create them as if perf_event_attr::disabled=1 and requires
perf_event_enable() after the CPU comes online (mirroring how offline
does an implicit perf_event_disable() as per the previous patch).


--- a/kernel/events/core.c
+++ b/kernel/events/core.c
@@ -2427,6 +2427,24 @@ perf_install_in_context(struct perf_even
 	smp_store_release(&event->ctx, ctx);
 
 	if (!task) {
+		/*
+		 * Check if the @cpu we're creating an event for is offline.
+		 *
+		 * We use the perf_cpu_context::ctx::mutex to serialize against
+		 * the hotplug notifiers. See perf_event_{init,exit}_cpu().
+		 */
+		struct perf_cpu_context *cpuctx =
+			container_of(ctx, struct perf_cpu_context, ctx);
+
+		if (!cpuctx->online) {
+			raw_spin_lock_irq(&ctx->lock);
+			add_event_to_context(event, ctx);
+			event->state = PERF_EVENT_STATE_OFF +
+				       PERF_EVENT_STATE_HOTPLUG_OFFSET;
+			raw_spin_unlock_irq(&ctx->lock);
+			return;
+		}
+
 		cpu_function_call(cpu, __perf_install_in_context, event);
 		return;
 	}
@@ -10181,6 +10199,8 @@ SYSCALL_DEFINE5(perf_event_open,
 		 *
 		 * We use the perf_cpu_context::ctx::mutex to serialize against
 		 * the hotplug notifiers. See perf_event_{init,exit}_cpu().
+		 *
+		 * XXX not strictly required, preserves existing behaviour.
 		 */
 		struct perf_cpu_context *cpuctx =
 			container_of(ctx, struct perf_cpu_context, ctx);
@@ -10368,21 +10388,6 @@ perf_event_create_kernel_counter(struct
 		goto err_unlock;
 	}
 
-	if (!task) {
-		/*
-		 * Check if the @cpu we're creating an event for is online.
-		 *
-		 * We use the perf_cpu_context::ctx::mutex to serialize against
-		 * the hotplug notifiers. See perf_event_{init,exit}_cpu().
-		 */
-		struct perf_cpu_context *cpuctx =
-			container_of(ctx, struct perf_cpu_context, ctx);
-		if (!cpuctx->online) {
-			err = -ENODEV;
-			goto err_unlock;
-		}
-	}
-
 	if (!exclusive_event_installable(event, ctx)) {
 		err = -EBUSY;
 		goto err_unlock;

  reply	other threads:[~2017-09-01 20:32 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-08-25 10:03 WARNING: possible circular locking dependency detected Borislav Petkov
2017-08-25 11:45 ` Borislav Petkov
2017-08-25 14:47 ` Sebastian Andrzej Siewior
2017-08-25 16:12   ` Byungchul Park
2017-08-25 16:21     ` Thomas Gleixner
2017-08-28  7:41   ` Peter Zijlstra
2017-08-28 14:11   ` Peter Zijlstra
2017-08-29 19:34   ` Peter Zijlstra
2017-08-25 16:42 ` Sebastian Andrzej Siewior
2017-08-28 14:58 ` Peter Zijlstra
2017-08-28 15:06   ` Peter Zijlstra
2017-08-28 16:32     ` Peter Zijlstra
2017-08-29 17:40   ` Thomas Gleixner
2017-08-29 19:49     ` Peter Zijlstra
2017-08-29 20:10       ` Thomas Gleixner
2017-08-30  5:47         ` Peter Zijlstra
2017-08-31  7:08           ` Thomas Gleixner
2017-08-31  7:37             ` Peter Zijlstra
2017-08-31  7:55               ` Thomas Gleixner
2017-08-31  8:09                 ` Peter Zijlstra
2017-08-31  8:15                   ` Thomas Gleixner
2017-08-31 21:24                     ` Thomas Gleixner
2017-09-01 20:32                       ` Peter Zijlstra [this message]
  -- strict thread matches above, loose matches on Subject: below --
2018-11-14  2:41 Qian Cai

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170901203250.GS6524@worktop.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=bigeasy@linutronix.de \
    --cc=bp@alien8.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox