Re: i2c-core multiplexer handling triggers dep-lock validator

[Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>]

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