lkml.org 
[lkml]   [2006]   [Jul]   [9]   [last100]   RSS Feed
Views: [more markup]   [less markup]   [headers]   [forward]  
 
Messages in this thread
/
DateSun, 9 Jul 2006 03:45:09 -0700
FromAndrew Morton <>
SubjectRe: 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/

\
 
 \ /
  Last update: 2006-07-09 10:47    [W:1.635 / U:0.330 seconds]
©2003-2008 Jasper Spaans