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

[Michal Piotrowski]

Hi,

On 30/05/06, Dave Jones <davej@xxxxxxxxxx> wrote:
> On Tue, May 30, 2006 at 12:41:08AM +0200, Ingo Molnar wrote:
>
>  > > =====================================================
>  > > [ BUG: possible circular locking deadlock detected! ]
>  > > -----------------------------------------------------
>  > > modprobe/1942 is trying to acquire lock:
>  > > (&anon_vma->lock){--..}, at: [<c10609cf>] anon_vma_link+0x1d/0xc9
>  > >
>  > > but task is already holding lock:
>  > > (&mm->mmap_sem/1){--..}, at: [<c101e5a0>] copy_process+0xbc6/0x1519
>  > >
>  > > which lock already depends on the new lock,
>  > > which could lead to circular deadlocks!
>  >
>  > hm, this one could perhaps be a real bug. Dave: lockdep complains about
>  > having observed:
>  >
>  >      anon_vma->lock  =>   mm->mmap_sem
>  >      mm->mmap_sem    =>   anon_vma->lock
>  >
>  > locking sequences, in the cpufreq code. Is there some special runtime
>  > behavior that still makes this safe, or is it a real bug?
>
> I'm feeling a bit overwhelmed by the voluminous output of this checker.
> Especially as (directly at least) cpufreq doesn't touch vma's, or mmap's.
>
> The first stack trace it shows has us down in the bowels of cpu hotplug,
> where we're taking the cpucontrol sem.  The second stack trace shows
> us in cpufreq_update_policy taking a per-cpu data->lock semaphore.
>
> Now, I notice this is modprobe triggering this, and this *looks* like
> we're loading two modules simultaneously (the first trace is from a
> scaling driver like powernow-k8 or the like, whilst the second trace
> is from cpufreq-stats).

/etc/init.d/cpuspeed starts very early
$ ls /etc/rc5.d/ | grep cpu
S06cpuspeed

I have this in my /etc/rc.local
modprobe -i cpufreq_conservative
modprobe -i cpufreq_ondemand
modprobe -i cpufreq_powersave
modprobe -i cpufreq_stats
modprobe -i cpufreq_userspace
modprobe -i freq_table

> How on earth did we get into this situation?

Just before gdm starts, while /etc/rc.local is processed.

> module loading is supposed
> to be serialised on the module_mutex no ?
>
> It's been a while since a debug patch has sent me in search of paracetamol ;)
>
>                 Dave

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group
(http://www.stardust.webpages.pl/ltg/wiki/)
-
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/