Re: 2.6.18-rc1-mm1

[Nick Piggin <nickpiggin@yahoo.com.au>]

Andrew Morton wrote:
> 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.

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