Re: lockdep splat involving iio-hwmon and iio-rescale drivers

[Rasmus Villemoes <ravi@prevas.dk>]

On Thu, Dec 11 2025, Peter Rosin <peda@axentia.se> wrote:

> 2025-12-10 at 23:54, Peter Rosin wrote:
>> Before commit 3092bde731ca ("iio: inkern: move to the cleanup.h
>> magic") I think this could have been solved with a number of:
>> 
>> -	mutex_lock(&iio_dev_opaque->info_exist_lock);
>> +	mutex_lock_nested(&iio_dev_opaque->info_exist_lock);
>
> Oops, we need something clever for the (missing) subclass
> argument to the mutex_lock_nested() calls, which I simply forgot
> all about. It should have been:
>
> +	mutex_lock_nested(&iio_dev_opaque->info_exist_lock, *subclass*);
>
> I don't know what sane subclasses there are. One thing could be
> the recursion depth, but I don't think we want to keep track of that
> just for lockdep? Another is to use one lockdep class for every
> info_exist_lock, but that can generate a lot of lockdep classes...

It doesn't seem to me that that info_exist_lock is the proper
mechanism for whatever it is it is protecting against.

I'm not even sure it's needed, because if the device could be
unregistered while somebody has a reference to it, why is it even
allowed to take that lock in the first place (i.e., why is the memory
containing the info_exist_lock guaranteed to still be valid)?

But, since I'm not going to propose just ripping it out, perhaps a
better approach would be something like what the gpio subsystem did in
d83cee3d2bb1 ("gpio: protect the pointer to gpio_chip in gpio_device
with SRCU"), at least superficially it seems to be about a similar
problem.

Rasmus