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
- Follow-Ups:
- Re: lockdep problem conversion semaphore->mutex (dev->sem)
- From: Peter Zijlstra <[email protected]>
- Re: lockdep problem conversion semaphore->mutex (dev->sem)
- Prev by Date: Re: programs vanish with 2.6.22+
- Next by Date: Re: 2.6.24-rc4-mm1 and Very Slow PCMCIA Compact Flash
- Previous by thread: BUG: soft lockup - CPU#1 stuck for 15s! [swapper:0]
- Next by thread: Re: lockdep problem conversion semaphore->mutex (dev->sem)
- Index(es):
 |