Hi Michael,
On Tue, 04 Sep 2012 14:19:47 +0200, Michael Lawnick wrote:
> Hi Jean, *
>
> our local kernel maintainers decided to switch on lock dependency check
> (CONFIG_PROVE_LOCKING) and this got a hit when multiplexer is removed
> while sub devices to its ports are registered:
> > hpd_i2c_disconn/15357 is trying to acquire lock:
> > (&adap->userspace_clients_lock){+.+.+.}, at: [<ffffffff80417a14>]
> > i2c_del_adapter+0xe4/0x350
> >
> > but task is already holding lock:
> > (&adap->userspace_clients_lock){+.+.+.}, at: [<ffffffff804174cc>]
> > i2c_sysfs_delete_device+0x74/0x218
> >
> > other info that might help us debug this:
> > 2 locks held by hpd_i2c_disconn/15357:
> > #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff80276d4c>]
> > sysfs_write_file+0x4c/0x208
> > #1: (&adap->userspace_clients_lock){+.+.+.}, at: [<ffffffff804174cc>]
> > i2c_sysfs_delete_device+0x74/0x218
>
> Looking into matters I found that all is ok, this is a false positive.
> lockdep-design.txt handles this situation on a hard-disc example and
> recommends usage of mutex_lock_nested().
>
> Are you already aware of the problem, even have already a patch in queue
> or is this waiting for a volunteer?
First time I hear about this, so I don't have a patch. I'll happily
receive one, review it and test it.
Thanks,
--
Jean Delvare
--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
