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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).