| Message ID | 20220517075518.43613-1-alexander.sverdlin@nokia.com |
|---|---|
| State | New |
| Headers | show |
| Series | i2c: core: Workaround false-positive LOCKDEP in delete_device | expand |
> + /* > + * We drop the mutex here, because device unregister > + * will take sysfs lock (kn->count) which, as LOCKDEP > + * would think, depends on this mutex > + */ I have to ask: can't lockdep be fixed or the lock somehow be annotated to prevent the false positive?
Hello Wolfram, On 21/05/2022 11:50, Wolfram Sang wrote: >> + /* >> + * We drop the mutex here, because device unregister >> + * will take sysfs lock (kn->count) which, as LOCKDEP >> + * would think, depends on this mutex >> + */ > I have to ask: can't lockdep be fixed or the lock somehow be annotated > to prevent the false positive? I would be happy to test any other proposal, I personally didn't find other working approach until now. This particular patch actually has an advantage of reducing the locked region, which makes sense if only userspace_clients is protected by the mutex.
diff --git a/drivers/i2c/i2c-core-base.c b/drivers/i2c/i2c-core-base.c index d43db2c..bd2e3e4 100644 --- a/drivers/i2c/i2c-core-base.c +++ b/drivers/i2c/i2c-core-base.c @@ -1272,9 +1272,14 @@ delete_device_store(struct device *dev, struct device_attribute *attr, "delete_device", client->name, client->addr); list_del(&client->detected); + /* + * We drop the mutex here, because device unregister + * will take sysfs lock (kn->count) which, as LOCKDEP + * would think, depends on this mutex + */ + mutex_unlock(&adap->userspace_clients_lock); i2c_unregister_device(client); - res = count; - break; + return count; } } mutex_unlock(&adap->userspace_clients_lock);