2.6.18-git21, possible recursive locking in kseriod ends up in DWARF2 unwinder stuck

2.6.18-git21, possible recursive locking in kseriod ends up in DWARF2 unwinder stuck

[Alessandro Suardi]

Non-fatal (box is still alive and apparently well) on boot,
 FC5-uptodate on a Dell Latitude C640. From the dmesg ring:

[    8.680000] =============================================
[    8.680000] [ INFO: possible recursive locking detected ]
[    8.680000] 2.6.18-git21 #1
[    8.680000] ---------------------------------------------
[    8.680000] kseriod/163 is trying to acquire lock:
[    8.680000]  (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
ps2_command+0x89/0x358
[    8.680000]
[    8.680000] but task is already holding lock:
[    8.680000]  (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
ps2_command+0x89/0x358
[    8.680000]
[    8.680000] other info that might help us debug this:
[    8.680000] 4 locks held by kseriod/163:
[    8.680000]  #0:  (serio_mutex){--..}, at: [<c0317a5f>]
serio_thread+0x11/0x2ca
[    8.680000]  #1:  (&serio->drv_mutex){--..}, at: [<c0316f2c>]
serio_connect_driver+0x17/0x32
[    8.680000]  #2:  (psmouse_mutex){--..}, at: [<c0320a90>]
psmouse_connect+0x11/0x24a
[    8.680000]  #3:  (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
ps2_command+0x89/0x358
[    8.680000]
[    8.680000] stack backtrace:
[    8.680000]  [<c010339c>] show_trace_log_lvl+0x24/0x39
[    8.680000]  [<c0103b54>] dump_stack+0x24/0x28
[    8.680000]  [<c0129c8f>] __lock_acquire+0x128/0xa1c
[    8.680000]  [<c012a897>] lock_acquire+0x6a/0x84
[    8.680000]  [<c03d14f5>] mutex_lock_nested+0xd8/0x25b
[    8.680000]  [<c03198c3>] ps2_command+0x89/0x358
[    8.680000]  [<c031fed9>] psmouse_sliced_command+0x2c/0x74
[    8.680000]  [<c0323be0>] synaptics_pt_write+0x2a/0x5a
[    8.680000]  [<c031978e>] ps2_sendbyte+0x51/0xfd
[    8.680000]  [<c031994f>] ps2_command+0x115/0x358
[    8.680000]  [<c031fa59>] psmouse_probe+0x24/0x7d
[    8.680000]  [<c0320b8d>] psmouse_connect+0x10e/0x24a
[    8.680000]  [<c0316f36>] serio_connect_driver+0x21/0x32
[    8.680000]  [<c02e0615>] really_probe+0x3c/0xc3
[    8.680000]  [<c02dfaea>] bus_for_each_drv+0x52/0x84
[    8.680000]  [<c02e07a9>] device_attach+0x5e/0x72
[    8.680000]  [<c02dfa6c>] bus_attach_device+0x24/0x50
[    8.680000]  [<c02ded5c>] device_add+0x37d/0x4bf
[    8.680000]  [<c0317b29>] serio_thread+0xdb/0x2ca
[    8.680000]  [<c0123d19>] kthread+0xc5/0xf4
[    8.680000]  [<c0102edb>] kernel_thread_helper+0x7/0x10
[    8.680000] DWARF2 unwinder stuck at kernel_thread_helper+0x7/0x10
[    8.680000]
[    8.680000] Leftover inexact backtrace:
[    8.680000]
[    8.680000]  =======================


--alessandro

"Well a man has two reasons for things that he does
  the first one is pride and the second one is love
  all understandings must come by this way"

     (Husker Du, 'She Floated Away')

Re: 2.6.18-git21, possible recursive locking in kseriod ends up in DWARF2 unwinder stuck

[Jiri Kosina]

On Wed, 4 Oct 2006, Alessandro Suardi wrote:

> Non-fatal (box is still alive and apparently well) on boot,
> FC5-uptodate on a Dell Latitude C640. From the dmesg ring:

> [    8.680000] =============================================
> [    8.680000] [ INFO: possible recursive locking detected ]
> [    8.680000] 2.6.18-git21 #1
> [    8.680000] ---------------------------------------------
> [    8.680000] kseriod/163 is trying to acquire lock:
> [    8.680000]  (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
> ps2_command+0x89/0x358

Me and Peter Zijlstra have already submitted patches to fix this - read 
the thread at 
http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-09/msg07416.html

I don't know the reason why these have not yet been merged into the input 
tree. Dmitry?

Thanks,

-- 
Jiri Kosina

Re: 2.6.18-git21, possible recursive locking in kseriod ends up in DWARF2 unwinder stuck

[Dmitry Torokhov]

On 10/4/06, Jiri Kosina <jikos@jikos.cz> wrote:
> On Wed, 4 Oct 2006, Alessandro Suardi wrote:
>
> > Non-fatal (box is still alive and apparently well) on boot,
> > FC5-uptodate on a Dell Latitude C640. From the dmesg ring:
>
> > [    8.680000] =============================================
> > [    8.680000] [ INFO: possible recursive locking detected ]
> > [    8.680000] 2.6.18-git21 #1
> > [    8.680000] ---------------------------------------------
> > [    8.680000] kseriod/163 is trying to acquire lock:
> > [    8.680000]  (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
> > ps2_command+0x89/0x358
>
> Me and Peter Zijlstra have already submitted patches to fix this - read
> the thread at
> http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-09/msg07416.html
>
> I don't know the reason why these have not yet been merged into the input
> tree. Dmitry?
>

Sorry, was a little busy.

I tested the patches and they work. Couple of comments:

- register_lock_class is marked as inline but now has 2 call sites and
is relatively big - might want to remove "inline"
- how about adding lockdep_set_subclass() to avoid littering source
with struct lock_class_key when we only want to tweak subclass? For
that we might want export register_lock_class and hide it behind a
#define...

-- 
Dmitry

Re: 2.6.18-git21, possible recursive locking in kseriod ends up in DWARF2 unwinder stuck

[Jiri Kosina]

On Thu, 5 Oct 2006, Dmitry Torokhov wrote:

> I tested the patches and they work. Couple of comments:
> - register_lock_class is marked as inline but now has 2 call sites and
> is relatively big - might want to remove "inline"

I agree.

> - how about adding lockdep_set_subclass() to avoid littering source
> with struct lock_class_key when we only want to tweak subclass? For
> that we might want export register_lock_class and hide it behind a
> #define...

I added Ingo to CC so that he could comment.

However I would not be able to submit patches which will be tested, as the 
only machine I had with passthrough synpatics port broke horribly and is 
currently in the warranty repair.

-- 
Jiri Kosina

Re: 2.6.18-git21, possible recursive locking in kseriod ends up in DWARF2 unwinder stuck

[Peter Zijlstra]

On Thu, 2006-10-05 at 16:34 -0400, Dmitry Torokhov wrote:
> On 10/4/06, Jiri Kosina <jikos@jikos.cz> wrote:
> > On Wed, 4 Oct 2006, Alessandro Suardi wrote:
> >
> > > Non-fatal (box is still alive and apparently well) on boot,
> > > FC5-uptodate on a Dell Latitude C640. From the dmesg ring:
> >
> > > [    8.680000] =============================================
> > > [    8.680000] [ INFO: possible recursive locking detected ]
> > > [    8.680000] 2.6.18-git21 #1
> > > [    8.680000] ---------------------------------------------
> > > [    8.680000] kseriod/163 is trying to acquire lock:
> > > [    8.680000]  (&ps2dev->cmd_mutex/1){--..}, at: [<c03198c3>]
> > > ps2_command+0x89/0x358
> >
> > Me and Peter Zijlstra have already submitted patches to fix this - read
> > the thread at
> > http://linux.derkeiler.com/Mailing-Lists/Kernel/2006-09/msg07416.html
> >
> > I don't know the reason why these have not yet been merged into the input
> > tree. Dmitry?
> >
> 
> Sorry, was a little busy.
> 
> I tested the patches and they work. Couple of comments:
> 
> - register_lock_class is marked as inline but now has 2 call sites and
> is relatively big - might want to remove "inline"
> - how about adding lockdep_set_subclass() to avoid littering source
> with struct lock_class_key when we only want to tweak subclass? For
> that we might want export register_lock_class and hide it behind a
> #define...
> 

or something like this:

#define concat_i(a)	#a
#define concat(a,b)	concat_i(a ## b)

#define lockdep_set_subclass(lock, subclass) \
  ({ static struct lock_key_class __key; \
     lockdep_init_map(&(lock)->dep_map, concat(lock, subclass), \
                      &__key, subclass); })

Re: 2.6.18-git21, possible recursive locking in kseriod ends up in DWARF2 unwinder stuck

[Dmitry Torokhov]

On 10/6/06, Peter Zijlstra <a.p.zijlstra@chello.nl> wrote:
> > - how about adding lockdep_set_subclass() to avoid littering source
> > with struct lock_class_key when we only want to tweak subclass? For
> > that we might want export register_lock_class and hide it behind a
> > #define...
> >
>
> or something like this:
>
> #define concat_i(a)     #a
> #define concat(a,b)     concat_i(a ## b)
>
> #define lockdep_set_subclass(lock, subclass) \
>  ({ static struct lock_key_class __key; \
>     lockdep_init_map(&(lock)->dep_map, concat(lock, subclass), \
>                      &__key, subclass); })
>

That leaves unneeded __key (another one was already created by
mutex_init...) but it tucked away nicely in the define so it is fune
by me.

Ingo, do you want to send these changes on or you want me to push them
through my tree?

-- 
Dmitry

Re: 2.6.18-git21, possible recursive locking in kseriod ends up in DWARF2 unwinder stuck

[Ingo Molnar]

* Dmitry Torokhov <dmitry.torokhov@gmail.com> wrote:

> >#define lockdep_set_subclass(lock, subclass) \
> > ({ static struct lock_key_class __key; \
> >    lockdep_init_map(&(lock)->dep_map, concat(lock, subclass), \
> >                     &__key, subclass); })
> 
> That leaves unneeded __key (another one was already created by 
> mutex_init...) but it tucked away nicely in the define so it is fine 
> by me.
> 
> Ingo, do you want to send these changes on or you want me to push them 
> through my tree?

could you send that commit to Andrew? It looks good to me, and the 
unavailability of the lockdep_set_subclass() API upstream is hindering 
Jiri now.

	Ingo