lkml.org 
[lkml]   [2022]   [Aug]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH] iio: buffer: Silence lock nesting splat
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.

\
 
 \ /
  Last update: 2022-08-23 10:27    [W:0.237 / U:0.644 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site