The Linux Kernel Mailing List
 help / color / mirror / Atom feed
From: Jonathan Cameron <jic23@kernel.org>
To: Muchamad Coirul Anwar <muchamadcoirulanwar@gmail.com>
Cc: Danilo Krummrich <dakr@kernel.org>,
	lars@metafoo.de, linux-iio@vger.kernel.org,
	linux-kernel@vger.kernel.org, linux-i2c@vger.kernel.org,
	andi.shyti@kernel.org, wsa+renesas@sang-engineering.com,
	ojeda@kernel.org, igor.korotin@linux.dev, branstj@gmail.com
Subject: Re: [RFC PATCH v4 2/3] rust: add minimal IIO subsystem abstractions
Date: Mon, 3 Aug 2026 01:43:08 +0100	[thread overview]
Message-ID: <20260803014308.35ce74a5@jic23-huawei> (raw)
In-Reply-To: <CAO26r3QDbT07dTsMfMB8Y6H+qBzh-PQxgcTTVKqJ7C9yv-emsQ@mail.gmail.com>

On Tue, 14 Jul 2026 23:20:48 +0700
Muchamad Coirul Anwar <muchamadcoirulanwar@gmail.com> wrote:

> On Sat, 11 Jul 2026 at 19:12, Danilo Krummrich <dakr@kernel.org> 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


  reply	other threads:[~2026-08-03  0:43 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-07 15:15 [RFC PATCH v4 0/3] iio: position: add Rust driver for ams AS5600 Muchamad Coirul Anwar
2026-07-07 15:15 ` [RFC PATCH v4 1/3] i2c: rust: implement SMBus read abstraction via kernel::io::Io for I2cClient Muchamad Coirul Anwar
2026-07-11 10:05   ` Igor Korotin
2026-07-11 12:05     ` Danilo Krummrich
2026-07-14 16:08     ` Muchamad Coirul Anwar
2026-07-18  2:48       ` Bruce Robertson
2026-07-19 15:40         ` Muchamad Coirul Anwar
2026-07-19 23:02       ` Danilo Krummrich
2026-07-20  2:26         ` Muchamad Coirul Anwar
2026-07-11 12:08   ` Danilo Krummrich
2026-07-14 16:10     ` Muchamad Coirul Anwar
2026-08-03  0:53   ` Jonathan Cameron
2026-08-03  8:14     ` Muchamad Coirul Anwar
2026-07-07 15:15 ` [RFC PATCH v4 2/3] rust: add minimal IIO subsystem abstractions Muchamad Coirul Anwar
2026-07-11 12:12   ` Danilo Krummrich
2026-07-14 16:20     ` Muchamad Coirul Anwar
2026-08-03  0:43       ` Jonathan Cameron [this message]
2026-08-03  7:24         ` Muchamad Coirul Anwar
2026-07-07 15:15 ` [RFC PATCH v4 3/3] iio: position: add Rust driver for ams AS5600 Muchamad Coirul Anwar
2026-08-03  1:13   ` Jonathan Cameron
2026-08-06  1:54     ` Muchamad Coirul Anwar
2026-08-04 14:57   ` Nuno Sá
2026-08-06  2:51     ` Muchamad Coirul Anwar
2026-07-08 10:36 ` [RFC PATCH v4 0/3] " Miguel Ojeda
2026-07-08 12:37   ` Muchamad Coirul Anwar

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20260803014308.35ce74a5@jic23-huawei \
    --to=jic23@kernel.org \
    --cc=andi.shyti@kernel.org \
    --cc=branstj@gmail.com \
    --cc=dakr@kernel.org \
    --cc=igor.korotin@linux.dev \
    --cc=lars@metafoo.de \
    --cc=linux-i2c@vger.kernel.org \
    --cc=linux-iio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=muchamadcoirulanwar@gmail.com \
    --cc=ojeda@kernel.org \
    --cc=wsa+renesas@sang-engineering.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox