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

[Jonathan Cameron <jic23@kernel.org>]

On Mon, 22 Dec 2025 09:52:42 +0100
Rasmus Villemoes <ravi@prevas.dk> wrote:

> 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.

Thanks for doing the archeology.  I had a dig as well and fairly sure it's.
That references the rules for consumers in the commit message so definitely
seems that all the relevant infrastructure was in there at that point.
Given it's from 2012 we can backport this to all kernels anyone still cares
about.

 ac917a81117c ("staging:iio:core set the iio_dev.info pointer to null on unregister under lock.")

So applied with that fixes tag to the fixes-togreg branch of iio.git.

thanks,

Jonathan


> Rasmus