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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 8 Dec 2007 00:02:08 +0100
From:	"Remy Bohmer" <>
To:	"Peter Zijlstra" <>
Cc:	"Daniel Walker" <>,
	"Ingo Molnar" <>,
	"Steven Rostedt" <>,
	linux-kernel <>,
	"Dave Chinner" <>
Subject: lockdep problem conversion semaphore->mutex (dev->sem)

Hello Peter,

> > What specifically is wrong with dev->sem ?
> Nothing really, other than that they use semaphores to avoid lockdep :-/
> I think I know how to annotate this, after Alan Stern explained all the
> use cases, but I haven't come around to implementing it. Hope to do that
> soonish.

I was looking for an easy semaphore I could convert to a mutex, and I
ran into one that was widely spread and interesting, and which seemed
quite doable at first sight.
So, I started working on it, but was forgotten this discussion, (until
Daniel made me remember it this afternoon). So, I (stupid me ;-) )
tried to convert dev->sem...

After doing the monkey part of the conversion I can boot the kernel
completely on X86 and ARM, and everything works fine, except after
enabling lockdep, lockdep starts complaining...

Is this the problem you were pointing at?
Setting up standard PCI resources
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing

[ INFO: possible recursive locking detected ]
2.6.24-rc4 #5
swapper/1 is trying to acquire lock:
 (&dev->mut){--..}, at: [<c056760c>] __driver_attach+0x2c/0x5f

but task is already holding lock:
 (&dev->mut){--..}, at: [<c05675fd>] __driver_attach+0x1d/0x5f

other info that might help us debug this:
1 lock held by swapper/1:
 #0:  (&dev->mut){--..}, at: [<c05675fd>] __driver_attach+0x1d/0x5f

stack backtrace:
Pid: 1, comm: swapper Not tainted 2.6.24-rc4 #5
 [<c0448a25>] __lock_acquire+0x17b/0xb83
 [<c0448491>] trace_hardirqs_on+0x11a/0x13d
 [<c04497f9>] lock_acquire+0x5f/0x77
 [<c056760c>] __driver_attach+0x2c/0x5f
 [<c06210de>] mutex_lock_nested+0x105/0x26b
 [<c056760c>] __driver_attach+0x2c/0x5f
 [<c056760c>] __driver_attach+0x2c/0x5f
 [<c05675e0>] __driver_attach+0x0/0x5f
 [<c056760c>] __driver_attach+0x2c/0x5f
 [<c0566ba9>] bus_for_each_dev+0x3a/0x5c
 [<c05673ba>] driver_attach+0x16/0x18
 [<c05675e0>] __driver_attach+0x0/0x5f
 [<c0566ea0>] bus_add_driver+0x6d/0x19a
 [<c0762613>] acpi_ec_init+0x33/0x51
 [<c0749491>] kernel_init+0x148/0x2af
 [<c0749349>] kernel_init+0x0/0x2af
 [<c0749349>] kernel_init+0x0/0x2af
 [<c0405bd7>] kernel_thread_helper+0x7/0x10
ACPI: PCI Root Bridge [PCI0] (0000:00)
Force enabled HPET at base address 0xfed00000

I tried debugging it, and I have not found a recursive mutex locking
so far, only locking of 2 different mutexes in a row prior to this
warning, which IMO should be valid.

What is your opinion?

BTW: I attached my patch for dev->sem as I have it now, that generates
this lockdep warning ( for if you want to look at it yourself also, so
you do not have to do the monkey part yourself anymore ;-)

Kind Regards,


Download attachment "patch_replace_sem_by_mutex_in_device_h" of type "application/octet-stream" (29835 bytes)

Powered by blists - more mailing lists