On Sat, Aug 20, 2022 at 01:08:28PM +0200, Lars-Peter Clausen wrote: > There are two different approaches for this kind of nested locking. One > is to use mutex_lock_nested(). This works if there is a strict > hierarchy. The I2C framework for example has a function to determine the > position of a I2C mux in the hierarchy and uses that for locking. See > https://elixir.bootlin.com/linux/latest/source/drivers/i2c/i2c-core-base.c#L1151. > > I'm not sure this directly translates to IIO since the > consumers/producers don't have to be a in strict hierarchy. And if it > is a complex graph it can be difficult to figure out the right level for > mutex_lock_nested(). > > The other method is to mark each mutex as its own class. lockdep does > the lock checking based on the lock class and by default the same mutex > of different instances is considered the same class to keep the resource > requirements for the checker lower. > > Regmap for example does this. See > https://elixir.bootlin.com/linux/latest/source/drivers/base/regmap/regmap.c#L795. > > This could be a solution for IIO with the downside how the additional > work for the checker. But as long as there are only a few IIO devices > per system that should be OK. We could also only set the per device lock > class if in kernel consumers are enabled. The second method certainly sounds like a better fix, since it also still warns if one actually takes the same iio_dev mutex twice. I'll respin the patch. Thanks.
