Thread (36 messages) 36 messages, 4 authors, 2012-12-07

Re: [RFC PATCH v2 01/10] CPU hotplug: Provide APIs for "light" atomic readers to prevent CPU offline

From: Srivatsa S. Bhat <hidden>
Date: 2012-12-07 20:27:19
Also in: lkml

On 12/08/2012 01:26 AM, Oleg Nesterov wrote:
On 12/07, Srivatsa S. Bhat wrote:
quoted
On 12/06/2012 09:48 PM, Oleg Nesterov wrote:
quoted
On 12/06, Srivatsa S. Bhat wrote:
quoted
+void get_online_cpus_atomic(void)
+{
+	int c, old;
+
+	preempt_disable();
+	read_lock(&hotplug_rwlock);
Confused... Why it also takes hotplug_rwlock?
To avoid ABBA deadlocks.

hotplug_rwlock was meant for the "light" readers.
The atomic counters were meant for the "heavy/full" readers.
OK, I got lost a bit. I'll try to read v3 tomorrow.
OK, thanks! But note that v3 is completely different from v2.
quoted
quoted
Obviously you can't use get_online_cpus_atomic() under rq->lock or
task->pi_lock or any other lock CPU_DYING can take. Probably this is
fine, but perhaps it makes sense to add the lockdep annotations.
Hmm, you are right. We can't use _atomic() in the CPU_DYING path.
Not sure I undestand... I simply meant that, say,
get_online_cpus_atomic() under task->pi_lock can obviously deadlock
with take_cpu_down() which can want the same task->pi_lock after
disable_atomic_reader().
Right, I mistook your point for something else (i.e., ability for
the writer to do get_online_cpus_atomic() safely, which I fixed in
v3).

So, your point above is very valid. And yes, we can't do much
about it, we'll just have to teach lockdep to catch such usages.

Regards,
Srivatsa S. Bhat
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help