lockdep problem conversion semaphore->mutex (dev->sem)

["Remy Bohmer" <linux@bohmer.net>]

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,

Remy

Attachment: patch_replace_sem_by_mutex_in_device_h
Description: Binary data