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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 06 Oct 2006 13:38:16 +0200
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Dmitry Torokhov <dmitry.torokhov@...il.com>
Cc:	Jiri Kosina <jikos@...os.cz>,
	Alessandro Suardi <alessandro.suardi@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>,
	Ingo Molnar <mingo@...e.hu>
Subject: Re: 2.6.18-git21, possible recursive locking in kseriod ends up in
	DWARF2 unwinder stuck

On Thu, 2006-10-05 at 16:34 -0400, Dmitry Torokhov wrote:
> On 10/4/06, Jiri Kosina <jikos@...os.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); })

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/