Re: lockdep whine in 2.6.26-rc2-mm1

["Dave Young" <hidave.darkstar@gmail.com>]

On Thu, May 15, 2008 at 12:24 AM, Matthew Wilcox <matthew@wil.cx> wrote:
> On Wed, May 14, 2008 at 08:56:39AM -0700, Greg KH wrote:
>> On Wed, May 14, 2008 at 12:09:33AM -0700, Andrew Morton wrote:
>> >
>> > =============================================
>> > [ INFO: possible recursive locking detected ]
>> > 2.6.26-rc2-mm1 #15
>> > ---------------------------------------------
>> > modprobe/942 is trying to acquire lock:
>> >  (&cls->mutex){--..}, at: [<ffffffff811b431e>] device_add+0x43d/0x57a
>> >
>> > but task is already holding lock:
>> >  (&cls->mutex){--..}, at: [<ffffffff811b6787>] class_interface_register+0x48/0xbd
>> >
>> > other info that might help us debug this:
>> > 1 lock held by modprobe/942:
>> >  #0:  (&cls->mutex){--..}, at: [<ffffffff811b6787>] class_interface_register+0x48/0xbd
>> >
>> > stack backtrace:
>> > Pid: 942, comm: modprobe Not tainted 2.6.26-rc2-mm1 #15
>> >
>> > Call Trace:
>> >  [<ffffffff81056be1>] __lock_acquire+0x90d/0xc50
>> >  [<ffffffff8100c50f>] ? restore_args+0x0/0x30
>> >  [<ffffffff811b431e>] ? device_add+0x43d/0x57a
>> >  [<ffffffff81057276>] lock_acquire+0x91/0xb7
>> >  [<ffffffff811b431e>] ? device_add+0x43d/0x57a
>> >  [<ffffffff812b23ab>] mutex_lock_nested+0xf2/0x278
>> >  [<ffffffff811b431e>] ? device_add+0x43d/0x57a
>> >  [<ffffffff812b3acd>] ? _spin_unlock+0x23/0x28
>> >  [<ffffffff811b431e>] device_add+0x43d/0x57a
>> >  [<ffffffff811b4471>] device_register+0x16/0x1b
>> >  [<ffffffff811b4555>] device_create+0xdf/0x112
>> >  [<ffffffff81055fdc>] ? trace_hardirqs_on+0xd/0xf
>> >  [<ffffffff81055fdc>] ? trace_hardirqs_on+0xd/0xf
>> >  [<ffffffff812b1fe1>] ? mutex_unlock+0x9/0xb
>> >  [<ffffffff811b79b7>] ? kobj_map+0x113/0x124
>> >  [<ffffffff810ac0f5>] ? exact_lock+0x0/0x14
>> >  [<ffffffff810abd09>] ? exact_match+0x0/0x9
>> >  [<ffffffffa00ec448>] :sg:sg_add+0x2a3/0x3bd
>> >  [<ffffffff811b67b6>] class_interface_register+0x77/0xbd
>> >  [<ffffffffa005d869>] :scsi_mod:scsi_register_interface+0x11/0x13
>> >  [<ffffffffa00d50a3>] :sg:init_sg+0xa3/0x155
>> >  [<ffffffff8105ea8f>] sys_init_module+0x1823/0x197a
>> >  [<ffffffff810c45bc>] ? seq_release+0x0/0x56
>> >  [<ffffffff8100bebb>] system_call_after_swapgs+0x7b/0x80
>>
>> I'm guessing that this is due to David's "change the semaphore to a
>> mutex" patch that you have in your tree, but I refused to take as I was
>> worried about just this issue :)
>
> Hm, I thought I saw the same patch from Arjan months ago ... anyway.
>
> class_interface_register() (at least in -rc2) holds &parent->sem (ie the
> result of calling class_get() on the class) around calling ->add_dev.
> The class in this case is the sg_sysfs_class, so it's calling sg_add().
> sg_add() calls device_create() which calls device_add() which acquires
> the &dev->class->sem.  The class in this case would _also_ seem to be
> sg_sysfs_class.
>
> So why doesn't this deadlock today?

The classes are different here, first sdev_class, then sg_sysfs_class

Regards
dave