Re: [PATCH] iio: core: add separate lockdep class for info_exist_lock

[Rasmus Villemoes <ravi@prevas.dk>]

On Sun, Dec 21 2025, Jonathan Cameron <jic23@kernel.org> wrote:

> On Mon, 15 Dec 2025 14:33:38 +0100
> Peter Rosin <peda@axentia.se> wrote:
>
>> Hi!
>> 
>> 2025-12-15 at 14:17, Rasmus Villemoes wrote:
>> > When one iio device is a consumer of another, it is possible that
>> > the ->info_exist_lock of both ends up being taken when reading the
>> > value of the consumer device.
>> > 
>> > Since they currently belong to the same lockdep class (being
>> > initialized in a single location with mutex_init()), that results in a
>> > lockdep warning  
>> 
>> ...
>> 
>> > Just as the mlock_key already has its own lockdep class, add a
>> > lock_class_key for the info_exist mutex.
>> > 
>> > Signed-off-by: Rasmus Villemoes <ravi@prevas.dk>  
>> 
>> Looks sane from here.
>> 
>> Reviewed-by: Peter Rosin <peda@axentia.se>
> Hi Rasmus,
>
> Thanks for doing this!
>> 
> We should probably merge this as a fix and get it backported.
> Whilst fairly rare anyone hits this it is also safe enough wrt
> to very low chance of causing any problems.
>
> Would be good to have an appropriate Fixes tag though.
> Ideally please reply to this thread with an appropriate one.
> If not I'll try and figure one out, but not today!

I tried to find one, but the problem goes way back, probably all the way
to either the introduction of info_exist_lock or the ability for one iio
channel to have a dependency on another, whichever came latest. And I'm
not really very familiar with the iio subsystem, so I couldn't find one
single commit to name.

Commit 2bc9cd66eb25d ("iio: Use per-device lockdep class for mlock")
which introduced the mlock_key referred to 67e17300dc1d76 ("iio:
potentiostat: add LMP91000 support"), but that feels more like a "this
driver is what first exposed the problem" and not really "this is where
the problem was introduced in the iio framework".

Wrt. backporting, it's probably worth mentioning c76ba4b264442 ("iio:
core: Replace lockdep_set_class() + mutex_init() by combined call") as a
prerequisite, as that is needed to make it cherry-pick cleanly.

Rasmus