All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Dave Jones <davej@redhat.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	"Rafael J. Wysocki" <rjw@rjwysocki.net>,
	Pavel Machek <pavel@ucw.cz>,
	linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org
Subject: Re: lockdep splat in CPU hotplug
Date: Tue, 21 Oct 2014 09:23:30 -0700	[thread overview]
Message-ID: <20141021162330.GJ4977@linux.vnet.ibm.com> (raw)
In-Reply-To: <alpine.LNX.2.00.1410211802500.24255@pobox.suse.cz>

On Tue, Oct 21, 2014 at 06:04:52PM +0200, Jiri Kosina wrote:
> On Tue, 21 Oct 2014, Paul E. McKenney wrote:
> 
> > > Looks like this indeed is something that lockdep *should* report (*), 
> > > although I would be suprised that stack unwinder would be so confused 
> > > by this -- there is no way for synchronize_sched_expedited() to be 
> > > inlined all the way to cpuidle_pause().
> > 
> > I think that if synchronize_sched_expedited() was in fact called, it
> > had already returned by the time we hit this problem.  But I must confess
> > that I am not seeing how cpuidle_uninstall_idle_handler() gets to
> > synchronize_rcu().
> 
> Umm, it directly calls it? :-)
> 
> 	void cpuidle_uninstall_idle_handler(void)
> 	{
> 		if (enabled_devices) {
> 			initialized = 0;
> 			wake_up_all_idle_cpus();
> 		}
> 
> 		/*
> 		 * Make sure external observers (such as the scheduler)
> 		 * are done looking at pointed idle states.
> 		 */
> 		synchronize_rcu();
> 	}

Ah, it would help if I did "git checkout linus/master" after updating,
wouldn't it now?

> > > (*) there are multiple places where cpu_hotplug.lock -> cpuidle_lock lock 
> > >     dependency is assumed. The patch that Dave pointed out adds 
> > >     cpuidle_lock -> cpu_hotplug.lock dependency.
> > > 
> > > Still not clear whether this is what's happening here ... anyway, adding 
> > > Paul to CC.
> > 
> > Hmmm...
> > 
> > Both cpuidle_pause() and cpuidle_pause_and_lock() acquire cpuidle_lock,
> > and are at the top of both stacks.  Which was the original confusion.  ;-)
> 
> Yup, they are, but lockdep is complaining about cpuidle_pause() acquiring 
> cpu_hotplug.lock ...

If it was attempting to acquire it via synchronize_sched_expedited(),
the attempt would fail and synchronize_sched_expedited() would fall
back to synchronize_sched()'s normal grace-period mechanism.  (Not to
synchronize_sched() itself, of course, as that would be infinite
recursion.)

So I believe that something else is going on here.

							Thanx, Paul

  reply	other threads:[~2014-10-21 16:23 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-21 11:09 lockdep splat in CPU hotplug Jiri Kosina
2014-10-21 14:58 ` Steven Rostedt
2014-10-21 15:04   ` Jiri Kosina
2014-10-22 18:37     ` Steven Rostedt
2014-10-22 18:40       ` Jiri Kosina
2014-10-22 18:46         ` Borislav Petkov
2014-10-21 15:10 ` Dave Jones
2014-10-21 15:21   ` Jiri Kosina
2014-10-21 16:00     ` Paul E. McKenney
2014-10-21 16:04       ` Jiri Kosina
2014-10-21 16:23         ` Paul E. McKenney [this message]
2014-10-22  9:53 ` Jiri Kosina
2014-10-22 11:39   ` Jiri Kosina
2014-10-22 14:28   ` Daniel Lezcano
2014-10-22 14:36     ` Jiri Kosina
2014-10-22 14:45       ` Daniel Lezcano
2014-10-22 14:38   ` Paul E. McKenney
2014-10-22 16:54     ` Paul E. McKenney
2014-10-22 18:57       ` Paul E. McKenney
2014-10-22 20:57         ` Jiri Kosina
2014-10-22 21:09           ` Paul E. McKenney
2014-10-23  8:11             ` Borislav Petkov
2014-10-23 14:56               ` Paul E. McKenney
2014-10-22 16:59   ` Steven Rostedt
2014-10-22 17:26     ` Jiri Kosina
2014-10-24 14:33   ` Peter Zijlstra

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=20141021162330.GJ4977@linux.vnet.ibm.com \
    --to=paulmck@linux.vnet.ibm.com \
    --cc=davej@redhat.com \
    --cc=jkosina@suse.cz \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-pm@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=pavel@ucw.cz \
    --cc=peterz@infradead.org \
    --cc=rjw@rjwysocki.net \
    /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 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.