From: Dmitry Torokhov <dtor_core@ameritech.net>
To: Andrew Morton <akpm@osdl.org>
Cc: "Linux Portal" <linportal@gmail.com>,
arjanv@redhat.com, mingo@redhat.com,
linux-kernel@vger.kernel.org
Subject: Re: Kernel lock bug detected (kseriod)
Date: Fri, 2 Jun 2006 21:52:00 -0400 [thread overview]
Message-ID: <200606022152.01515.dtor_core@ameritech.net> (raw)
In-Reply-To: <20060602161354.687168de.akpm@osdl.org>
On Friday 02 June 2006 19:13, Andrew Morton wrote:
> "Linux Portal" <linportal@gmail.com> wrote:
> >
> > Yes, it was observed on 2.6.17-rc5-mm2. Of specific stuff I have
> > synaptics driver compiled in (together with psmouse - bug was observed
> > on a laptop - during the boot sequence!). If you need more info about
> > the machine or its configuration, feel free to ask. For the time being
> > I'm sending just what the kernel lock validator left in my kernel
> > log. And keep up the good work, the lock validator is definitely some
> > fine piece of art!
> >
> >
> > Synaptics Touchpad, model: 1, fw: 5.9, id: 0x1b6eb1, caps: 0xa84793/0x100000
> > serio: Synaptics pass-through port at isa0060/serio4/input0
> > input: SynPS/2 Synaptics TouchPad as /class/input/input2
> > ====================================
> > [ BUG: possible deadlock detected! ]
> > ------------------------------------
> > kseriod/133 is trying to acquire lock:
> > (&ps2dev->cmd_mutex){--..}, at: [<7846b4e8>] mutex_lock+0x8/0x10
> >
> > but task is already holding lock:
> > (&ps2dev->cmd_mutex){--..}, at: [<7846b4e8>] mutex_lock+0x8/0x10
> >
> > which could potentially lead to deadlocks!
> >
> > other info that might help us debug this:
> > 4 locks held by kseriod/133:
> > #0: (serio_mutex){--..}, at: [<7846b4e8>] mutex_lock+0x8/0x10
> > #1: (&serio->drv_mutex){--..}, at: [<7846b4e8>] mutex_lock+0x8/0x10
> > #2: (psmouse_mutex){--..}, at: [<7846b4e8>] mutex_lock+0x8/0x10
> > #3: (&ps2dev->cmd_mutex){--..}, at: [<7846b4e8>] mutex_lock+0x8/0x10
> >
> > stack backtrace:
> > <78105572> show_trace+0x12/0x20 <78105599> dump_stack+0x19/0x20
> > <7813920e> __lockdep_acquire+0x54e/0xe00 <78139f2a> lockdep_acquire+0x7a/0xa0
> > <7846b3c9> __mutex_lock_slowpath+0x49/0x160 <7846b4e8> mutex_lock+0x8/0x10
> > <7834497b> ps2_command+0x3b/0x3c0 <7834ad22> psmouse_sliced_command+0x22/0x70
> > <7834f471> synaptics_pt_write+0x21/0x50 <78344736> ps2_sendbyte+0x46/0x120
> > <78344a29> ps2_command+0xe9/0x3c0 <7834ae8d> psmouse_probe+0x1d/0xa0
> > <7834c537> psmouse_connect+0x137/0x200 <78341649>
> > serio_connect_driver+0x29/0x50
> > <783419b6> serio_driver_probe+0x16/0x20 <782a8fb4>
> > driver_probe_device+0x44/0xd0
> > <782a9048> __device_attach+0x8/0x10 <782a8563> bus_for_each_drv+0x63/0x90
> > <782a90a6> device_attach+0x56/0x60 <782a868e> bus_attach_device+0x1e/0x40
> > <782a7763> device_add+0x113/0x180 <7834299d> serio_thread+0x1cd/0x2bb
> > <781322c6> kthread+0xc6/0xca <78101005> kernel_thread_helper+0x5/0xb
> >
>
> Thanks.
>
> So we're taking ps2->cmd_mutex and then we're recurring back into
> ps2_command() and then taking ps2->serio->cmd_mutex.
>
Right, these are 2 different mutextes, one protects the child
PS/2 device and the other protects parent PS/2 device accessed
via pass-through port (synaptics_pt_write).
> I suspect that's all correct/natural/expected and needs another
> make-lockdep-shut-up patch.
>
>
--
Dmitry
next prev parent reply other threads:[~2006-06-03 1:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-02 16:53 Kernel lock bug detected (kseriod) Linux Portal
2006-06-02 23:13 ` Andrew Morton
2006-06-03 1:52 ` Dmitry Torokhov [this message]
2006-06-03 8:50 ` [patch] Declare explicit, hardware based lock ranking in serio Arjan van de Ven
2006-06-03 11:56 ` Dmitry Torokhov
2006-06-03 12:11 ` Arjan van de Ven
2006-06-03 16:11 ` Dmitry Torokhov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200606022152.01515.dtor_core@ameritech.net \
--to=dtor_core@ameritech.net \
--cc=akpm@osdl.org \
--cc=arjanv@redhat.com \
--cc=linportal@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.