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?
--
KR
Michael
--
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
