Re: [patch 00/61] ANNOUNCE: lock validator -V1

[Dominik Brodowski]

Hi,

On Tue, May 30, 2006 at 10:58:52AM -0400, Dave Jones wrote:
> On Tue, May 30, 2006 at 04:19:22PM +0200, Arjan van de Ven wrote:
> 
>  > >  > One
>  > >  > ---
>  > >  > store_scaling_governor takes policy->lock and then calls __cpufreq_set_policy
>  > >  > __cpufreq_set_policy calls __cpufreq_governor
>  > >  > __cpufreq_governor  calls __cpufreq_driver_target via cpufreq_governor_performance
>  > >  > __cpufreq_driver_target calls lock_cpu_hotplug() (which takes the hotplug lock)
>  > >  > 
>  > >  > 
>  > >  > Two
>  > >  > ---
>  > >  > cpufreq_stats_init lock_cpu_hotplug() and then calls cpufreq_stat_cpu_callback
>  > >  > cpufreq_stat_cpu_callback calls cpufreq_update_policy
>  > >  > cpufreq_update_policy takes the policy->lock
>  > >  > 
>  > >  > 
>  > >  > so this looks like a real honest AB-BA deadlock to me...
>  > > 
>  > > This looks a little clearer this morning.  I missed the fact that sys_init_module
>  > > isn't completely serialised, only the loading part. ->init routines can and will be
>  > > called in parallel.
>  > > 
>  > > I don't see where cpufreq_update_policy takes policy->lock though.
>  > > In my tree it just takes the per-cpu data->lock.
>  > 
>  > isn't that basically the same lock?
> 
> Ugh, I've completely forgotten how this stuff fits together.
> 
> Dominik, any clues ?

That's indeed a possible deadlock situation -- what's the
cpufreq_update_policy() call needed for in cpufreq_stat_cpu_callback anyway?

	Dominik
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/