Re: [RFC PATCH v4 2/3] rust: add minimal IIO subsystem abstractions

On Mon, 3 Aug 2026 at 07:43, Jonathan Cameron <[email protected]> wrote:

> > From what I traced, yes. iio_device_unregister goes through
> > cdev_device_del, device_del, sysfs_remove_dir, and ends up in
> > kernfs_drain which waits for active sysfs readers to finish.
> > Please correct me if I'm missing something here.
> >
>
> That covers sysfs, but IIO has a bunch of chrdevs (though you aren't
> using them here).  I'd go for 'almost certainly' for whether synchronizes
> in all cases but we have found one or two races over the years.
>
> The way it is supposed to work is that the unregister takes the
> info_exist_lock and sets the iio_dev->info pointer to NULL.
> It also wakes up any one polling etc, and returns errors on all
> in flight actions.  Every ioctl takes that same lock and checks
> if info is null before carrying on.  The lock is held across
> the ioctl to stop any racing with the unregister path.
>
> I can't recall any recent paths being discovered where the
> lock + check was missed but we did have them in the past, though
> normally not about IOCTLs but about in kernel consumer drivers.
>
> There is an outstanding fix related to those, and read_avail
> + lifetimes if people allocate storage in that callback but
> I doubt this goes anywhere near that area of IIO yet.

Thanks, Jonathan.

The lock+check mechanism makes sense. AS5600 only implements read_raw
and doesn't use chrdevs or allocate storage in callbacks, so it should
be safe from the race you mentioned.

I will fix the SAFETY comment in iio.rs. The current wording is too
broad, so I'll narrow it down to describe the two separate sync paths
(kernfs_drain vs info_exist_lock).

Coirul