lkml.org 
[lkml]   [2006]   [Jul]   [26]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [patch] Reorganize the cpufreq cpu hotplug locking to not be totally bizare


On Wed, 26 Jul 2006, Srivatsa Vaddagiri wrote:
>
> __create_workqueue(), destroy_workqueue() and flush_workqueue() are all
> taking CPU hotplug lock currently. AFAICS they all can block and so
> disabling preemption wont work. What am I missing?

Well, at least __create_workqueue() should hopefully be fixable in the
sense that you can do the blocking ops first, and then do the final part
of actually instantiating it with preemption disabled.

But I agree with Arjan - I think the fundamental problem is that cpu
hotplug locking is just is fundamentally badly designed as-is. There's
really very little point to making it a _lock_ per se, since most people
really want more of a "I'm using this CPU, don't try to remove it right
now" thing which is more of a ref-counting-like issue.

I think we're hopefully ok for now in the AB-BA deadlock department (and I
should probably remove the recursion warning), and will need to revisit
things again after 2.6.18 to try to see if we can fix it properly.

Do we have lockdep warnings remaining? I'd hope that Arjan's earlier patch
(the one I already applied) got all of those, and that we at least thus
would have some basis for the belief that we got the ABBA deadlocks fixed.

Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2009-11-18 23:46    [W:1.054 / U:0.016 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site