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

[Rasmus Villemoes <ravi@prevas.dk>]

On Sun, Dec 14 2025, Peter Rosin <peda@axentia.se> wrote:

> On December 13, 2025 5:57:23 PM GMT+01:00, Jonathan Cameron <jic23@kernel.org> wrote:
>> I'm a bit curious we haven't seen many reports of this one. Whilst
>> there are relatively few IIO drivers that consume other IIO driver
>> provided channels it's also not a particularly new thing.
>
> I suspect the reason is that plain old iio_read_channel_raw does not
> grab the info_exist_lock, so it seems that you need two levels of
> iio_read_channel_processed[_scale] (or something like that). Which
> is rarer still.

As Jonathan pointed out, that function does grab the
info_exist_lock. However, when reading the attributes via the
/sys/bus/iio/..., that seems to go through iio_read_channel_info() which
does not.

So when reading the value of a "rescale" device via /sys/bus/iio/, the
info_exist_lock of the outer device is not taken, only of the underlying
voltage channel. But the splat can be obtained without involving the
hwmon bridge, if one chains "rescale" devices (this doesn't necessarily
describe any existing hardware or even make sense, just for demonstration)

 	foo: foo {
 		compatible = "voltage-divider";
 		io-channels = <&am335x_adc 0>;
 		#io-channel-cells = <1>;
 		output-ohms = <10000>;
 		full-ohms = <110000>;
 	};
 	bar: bar {
 		compatible = "voltage-divider";
 		io-channels = <&foo 0>;
 		#io-channel-cells = <1>;
 		output-ohms = <1234>;
 		full-ohms = <2345>;
 	};

results in

        CPU0
        ----
   lock(&iio_dev_opaque->info_exist_lock);
   lock(&iio_dev_opaque->info_exist_lock);
 
  *** DEADLOCK ***
 
  May be due to missing lock nesting notation
 
 4 locks held by cat/478:
  #0: c3721b5c (&p->lock){+.+.}-{3:3}, at: seq_read_iter+0x44/0x4e4
  #1: c4d1e284 (&of->mutex){+.+.}-{3:3}, at: kernfs_seq_start+0x1c/0xac
  #2: c2805a18 (kn->active#32){.+.+}-{0:0}, at: kernfs_seq_start+0x30/0xac
  #3: c1d96b68 (&iio_dev_opaque->info_exist_lock){+.+.}-{3:3}, at: iio_read_channel_raw+0x20/0x6c
 
 stack backtrace:
 CPU: 0 UID: 0 PID: 478 Comm: cat Not tainted 6.17.11 #6 NONE 
 Hardware name: Generic AM33XX (Flattened Device Tree)
 Call trace: 
  unwind_backtrace from show_stack+0x10/0x14
  show_stack from dump_stack_lvl+0x44/0x60
  dump_stack_lvl from print_deadlock_bug+0x2b8/0x334
  print_deadlock_bug from __lock_acquire+0x13a4/0x2ab0
  __lock_acquire from lock_acquire+0xd0/0x2c0
  lock_acquire from __mutex_lock+0xa0/0xe8c
  __mutex_lock from mutex_lock_nested+0x1c/0x24
  mutex_lock_nested from iio_read_channel_raw+0x20/0x6c
  iio_read_channel_raw from rescale_read_raw+0x128/0x1c4
  rescale_read_raw from iio_channel_read+0xe4/0xf4
  iio_channel_read from iio_read_channel_raw+0x44/0x6c
  iio_read_channel_raw from rescale_read_raw+0x128/0x1c4
  rescale_read_raw from iio_read_channel_info+0xfc/0x11c
  iio_read_channel_info from dev_attr_show+0x18/0x48
  dev_attr_show from sysfs_kf_seq_show+0x80/0x110
  sysfs_kf_seq_show from seq_read_iter+0xdc/0x4e4
  seq_read_iter from copy_splice_read+0x180/0x300
  copy_splice_read from splice_direct_to_actor+0xb4/0x2b8
  splice_direct_to_actor from do_splice_direct+0x7c/0xc8
  do_splice_direct from do_sendfile+0x314/0x3ac
  do_sendfile from sys_sendfile64+0x130/0x14c
  sys_sendfile64 from ret_fast_syscall+0x0/0x1c

I'll try to add that separate lockdep class. It should be fairly
mechanical (famous last words).

Rasmus