| Date | Sun, 9 Jul 2006 03:45:09 -0700 | From | Andrew Morton <> | Subject | Re: 2.6.18-rc1-mm1 |
| |
On Sun, 9 Jul 2006 12:26:45 +0200 "Fabio Comolli" <fabio.comolli@gmail.com> 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 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/
|