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.
- 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.
Voila, no more lock_cpu_hotplug().
-
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]
