From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: David Hildenbrand <dahi@linux.vnet.ibm.com>,
linux-kernel@vger.kernel.org, heiko.carstens@de.ibm.com,
borntraeger@de.ibm.com, rafael.j.wysocki@intel.com,
peterz@infradead.org, bp@suse.de, jkosina@suse.cz
Subject: Re: [PATCH v3] CPU hotplug: active_writer not woken up in some cases - deadlock
Date: Tue, 9 Dec 2014 19:18:09 -0800 [thread overview]
Message-ID: <20141210031809.GO25340@linux.vnet.ibm.com> (raw)
In-Reply-To: <20141210002619.GB516@redhat.com>
On Wed, Dec 10, 2014 at 01:26:19AM +0100, Oleg Nesterov wrote:
> On 12/09, Paul E. McKenney wrote:
> >
> > Would wait_event()/wake_up() work for the wakeup-writer case?
>
> Yes, and in this case we could probably kill this puts_pending logic
> and avoid cpu_hotplug.lock in put_online_cpus() altogether? Can't we
> just make cpu_hotplug.refcount atomic_t?
Seems like that should be possible. That would certainly simplify the
wakeup logic from put_online_cpus(). It might even be possible to
avoid acquiring cpu_hotplug.lock in put_online_cpus(), though that
would of course require more luck than anyone deserves.
> Anyway, this makes me think again that this code should use percpu_rwsem.
> Perhaps I'll try to make a patch next week...
>
> (we need down_write_recursive_readers(), and probably rcusync patches).
Careful! You might end up re-introducing the deadlock that I used
puts_pending to get rid of. ;-)
Thanx, Paul
next prev parent reply other threads:[~2014-12-10 3:18 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-09 12:23 [PATCH v3] CPU hotplug: active_writer not woken up in some cases - deadlock David Hildenbrand
2014-12-09 14:19 ` Paul E. McKenney
2014-12-09 16:24 ` David Hildenbrand
2014-12-09 17:01 ` Paul E. McKenney
2014-12-10 0:26 ` Oleg Nesterov
2014-12-10 3:18 ` Paul E. McKenney [this message]
2014-12-10 0:12 ` Oleg Nesterov
2014-12-10 7:56 ` David Hildenbrand
2014-12-10 18:59 ` Oleg Nesterov
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=20141210031809.GO25340@linux.vnet.ibm.com \
--to=paulmck@linux.vnet.ibm.com \
--cc=borntraeger@de.ibm.com \
--cc=bp@suse.de \
--cc=dahi@linux.vnet.ibm.com \
--cc=heiko.carstens@de.ibm.com \
--cc=jkosina@suse.cz \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
/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.