lkml.org 
[lkml]   [2006]   [May]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [patch 00/61] ANNOUNCE: lock validator -V1
    Hi,

    On 30/05/06, Dave Jones <davej@redhat.com> 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@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-05-30 07:54    [W:0.023 / U:30.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site