Andrew Morton wrote:
On Sun, 9 Jul 2006 12:26:45 +0200
"Fabio Comolli" <[email protected]> wrote:
=======================================================
[ INFO: possible circular locking dependency detected ]
-------------------------------------------------------
cpuspeed/1520 is trying to acquire lock:
(&policy->lock){--..}, at: [<c02c130f>] mutex_lock+0x21/0x24
but task is already holding lock:
(cpucontrol){--..}, at: [<c02c130f>] mutex_lock+0x21/0x24
which lock already depends on the new lock.
Yeah, that's lock_cpu_hotplug(). We've made a complete and utter mess of
that thing.
And I don't know how to fix it, really. Is it a highly-localised innermost
lock? Or a broad-coverage outermost lock? Nobody knows, neither suits.
I'm suspecting is was a bad idea and we should just rip it out altogether.
- If a piece of kernel code is dealing with cpu-local data it needs to be
running atomically, and that'll hold off hot hotplug anyway.
These guys don't need lock_cpu_hotplug() today.
- If a piece of kernel code is dealing with per-cpu data and cannot run
atomically then it should have its own cpu hotplug handlers anyway. It
is up to that code (ie: cpufreq) to provide its own locking against its
own CPU hotplug callback.
This still does not solve this cpufreq problem where it is trying to
take the same lock twice down the same call path. Whether it is the
lock_cpu_hotplug mutex or another one, the code must be just busted.
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
