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

Jonathan Cameron <[email protected]> Mon, 3 Aug 2026 01:43:08 +0100
Newsgroups org.kernel.vger.linux-i2c,org.kernel.vger.linux-iio,org.kernel.vger.linux-kernel
Message-ID <20260803014308.35ce74a5@jic23-huawei>
On Tue, 14 Jul 2026 23:20:48 +0700
Muchamad Coirul Anwar <[email protected]> wrote:

> On Sat, 11 Jul 2026 at 19:12, Danilo Krummrich <[email protected]> wrote:
> >
> > On Tue Jul 7, 2026 at 5:15 PM CEST, Muchamad Coirul Anwar wrote:  
> > > Add safe Rust wrappers for the Linux IIO (Industrial I/O) subsystem:  
> >
> > Does IIO's iio_device_unregister() synchronize against in-flight IOCTLs?  
> 
> 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.

Jonathan

> Thanks
> Coirul