This series introduces Rust abstractions for io_uring commands
(`IORING_OP_URING_CMD`) and wires them up to the miscdevice framework,
allowing Rust drivers to handle io_uring passthrough commands.

The series is structured as follows:

1. Add io_uring C headers to Rust bindings.
2. Zero-init pdu in io_uring_cmd_prep() to avoid UB from stale data.
3. Core io_uring Rust abstractions (IoUringCmd, QueuedIoUringCmd,
   IoUringSqe, UringCmdAction type-state pattern).
4. MiscDevice trait extension with uring_cmd callback.
5. Sample demonstrating async uring_cmd handling via workqueue.

The sample completes asynchronously using a workqueue rather than
`io_uring_cmd_complete_in_task()`.  The latter is primarily needed
when completion originates from IRQ/softirq context (e.g. NVMe),
whereas workqueue workers already run in process context and can
safely call `io_uring_cmd_done()` directly.  A Rust binding for
`complete_in_task` can be added in a follow-up series.

Copy-based `read_pdu()`/`write_pdu()` are kept instead of returning
`&T`/`&mut T` references because the PDU is a `[u8; 32]` byte array
whose alignment may not satisfy `T`'s requirements.

Changes since v3:
- read_pdu(): replaced MaybeUninit + copy_nonoverlapping(c_void) with
  read_unaligned (Caleb, Benno).
- write_pdu(): fixed c_void cast to u8 in copy_nonoverlapping (Benno).
- IoUringSqe::opcode(): use read_volatile for SQE field access (Caleb).
- IoUringSqe::cmd_data(): removed unnecessary runtime opcode check;
  safety is guaranteed by construction since IoUringSqe can only be
  obtained from IoUringCmd::sqe() inside a uring_cmd callback (Caleb).
- Removed unused mut in sample WorkItem::run() (compiler warning).

Changes since v2:
- Adopted type-state pattern for IoUringCmd (IoUringCmd -> QueuedIoUringCmd)
  to enforce correct completion flow at compile time.
- UringCmdAction enum with Complete/Queued variants prevents returning
  Queued without holding a QueuedIoUringCmd handle.
- Fixed error code handling (use proper kernel error types).
- Suppressed unused result warning with `let _ = ...enqueue(work)`.

Sidong Yang (5):
  rust: bindings: add io_uring headers in bindings_helper.h
  io_uring/cmd: zero-init pdu in io_uring_cmd_prep() to avoid UB
  rust: io_uring: introduce rust abstraction for io-uring cmd
  rust: miscdevice: Add `uring_cmd` support
  samples: rust: Add `uring_cmd` example to `rust_misc_device`

 io_uring/uring_cmd.c             |   1 +
 rust/bindings/bindings_helper.h  |   2 +
 rust/helpers/helpers.c           |   1 +
 rust/helpers/io_uring.c          |   9 +
 rust/kernel/io_uring.rs          | 457 +++++++++++++++++++++++++++++++
 rust/kernel/lib.rs               |   1 +
 rust/kernel/miscdevice.rs        |  79 ++++++
 samples/rust/rust_misc_device.rs |  53 +++-
 8 files changed, 602 insertions(+), 1 deletion(-)
 create mode 100644 rust/helpers/io_uring.c
 create mode 100644 rust/kernel/io_uring.rs

-- 
2.43.0

On Wed, Apr 08, 2026 at 01:59:57PM +0000, Sidong Yang wrote:
> This series introduces Rust abstractions for io_uring commands
> (`IORING_OP_URING_CMD`) and wires them up to the miscdevice framework,
> allowing Rust drivers to handle io_uring passthrough commands.
> 
> The series is structured as follows:
> 
> 1. Add io_uring C headers to Rust bindings.
> 2. Zero-init pdu in io_uring_cmd_prep() to avoid UB from stale data.
> 3. Core io_uring Rust abstractions (IoUringCmd, QueuedIoUringCmd,
>    IoUringSqe, UringCmdAction type-state pattern).
> 4. MiscDevice trait extension with uring_cmd callback.
> 5. Sample demonstrating async uring_cmd handling via workqueue.
> 
> The sample completes asynchronously using a workqueue rather than
> `io_uring_cmd_complete_in_task()`.  The latter is primarily needed
> when completion originates from IRQ/softirq context (e.g. NVMe),
> whereas workqueue workers already run in process context and can
> safely call `io_uring_cmd_done()` directly.  A Rust binding for
> `complete_in_task` can be added in a follow-up series.
> 
> Copy-based `read_pdu()`/`write_pdu()` are kept instead of returning
> `&T`/`&mut T` references because the PDU is a `[u8; 32]` byte array
> whose alignment may not satisfy `T`'s requirements.

Samples are great and all, but I would really like to see a real user of
this before adding any more miscdev apis to the kernel.  Can you submit
this as a series that also adds the driver that needs this at the same
time?

thanks,

greg k-h

On Thu, Apr 09, 2026 at 07:25:23AM +0200, Greg Kroah-Hartman wrote:
> On Wed, Apr 08, 2026 at 01:59:57PM +0000, Sidong Yang wrote:
> > This series introduces Rust abstractions for io_uring commands
> > (`IORING_OP_URING_CMD`) and wires them up to the miscdevice framework,
> > allowing Rust drivers to handle io_uring passthrough commands.
> > 
> > The series is structured as follows:
> > 
> > 1. Add io_uring C headers to Rust bindings.
> > 2. Zero-init pdu in io_uring_cmd_prep() to avoid UB from stale data.
> > 3. Core io_uring Rust abstractions (IoUringCmd, QueuedIoUringCmd,
> >    IoUringSqe, UringCmdAction type-state pattern).
> > 4. MiscDevice trait extension with uring_cmd callback.
> > 5. Sample demonstrating async uring_cmd handling via workqueue.
> > 
> > The sample completes asynchronously using a workqueue rather than
> > `io_uring_cmd_complete_in_task()`.  The latter is primarily needed
> > when completion originates from IRQ/softirq context (e.g. NVMe),
> > whereas workqueue workers already run in process context and can
> > safely call `io_uring_cmd_done()` directly.  A Rust binding for
> > `complete_in_task` can be added in a follow-up series.
> > 
> > Copy-based `read_pdu()`/`write_pdu()` are kept instead of returning
> > `&T`/`&mut T` references because the PDU is a `[u8; 32]` byte array
> > whose alignment may not satisfy `T`'s requirements.
> 
> Samples are great and all, but I would really like to see a real user of
> this before adding any more miscdev apis to the kernel.  Can you submit
> this as a series that also adds the driver that needs this at the same
> time?

Hi Greg,

Thank you for the review.

We have an out-of-tree C driver at Furiosa AI for our AI inference
accelerator that uses uring_cmd.  This is our primary motivation for
these abstractions.

We are considering upstreaming the driver and porting parts of it to
Rust using these abstractions.  If we were to upstream the driver,
would it need to be based on the accel subsystem (DRM)?  Or would a
standalone PCI driver approach also be acceptable?

Thanks,
Sidong

> 
> thanks,
> 
> greg k-h

On Sat, Apr 11, 2026 at 12:16:39PM +0000, Sidong Yang wrote:
> On Thu, Apr 09, 2026 at 07:25:23AM +0200, Greg Kroah-Hartman wrote:
> > On Wed, Apr 08, 2026 at 01:59:57PM +0000, Sidong Yang wrote:
> > > This series introduces Rust abstractions for io_uring commands
> > > (`IORING_OP_URING_CMD`) and wires them up to the miscdevice framework,
> > > allowing Rust drivers to handle io_uring passthrough commands.
> > > 
> > > The series is structured as follows:
> > > 
> > > 1. Add io_uring C headers to Rust bindings.
> > > 2. Zero-init pdu in io_uring_cmd_prep() to avoid UB from stale data.
> > > 3. Core io_uring Rust abstractions (IoUringCmd, QueuedIoUringCmd,
> > >    IoUringSqe, UringCmdAction type-state pattern).
> > > 4. MiscDevice trait extension with uring_cmd callback.
> > > 5. Sample demonstrating async uring_cmd handling via workqueue.
> > > 
> > > The sample completes asynchronously using a workqueue rather than
> > > `io_uring_cmd_complete_in_task()`.  The latter is primarily needed
> > > when completion originates from IRQ/softirq context (e.g. NVMe),
> > > whereas workqueue workers already run in process context and can
> > > safely call `io_uring_cmd_done()` directly.  A Rust binding for
> > > `complete_in_task` can be added in a follow-up series.
> > > 
> > > Copy-based `read_pdu()`/`write_pdu()` are kept instead of returning
> > > `&T`/`&mut T` references because the PDU is a `[u8; 32]` byte array
> > > whose alignment may not satisfy `T`'s requirements.
> > 
> > Samples are great and all, but I would really like to see a real user of
> > this before adding any more miscdev apis to the kernel.  Can you submit
> > this as a series that also adds the driver that needs this at the same
> > time?
> 
> Hi Greg,
> 
> Thank you for the review.
> 
> We have an out-of-tree C driver at Furiosa AI for our AI inference
> accelerator that uses uring_cmd.  This is our primary motivation for
> these abstractions.
> 
> We are considering upstreaming the driver and porting parts of it to
> Rust using these abstractions.  If we were to upstream the driver,
> would it need to be based on the accel subsystem (DRM)?  Or would a
> standalone PCI driver approach also be acceptable?

Yes, it must use the accel subsystem as that is the correct api for it.

thanks,

greg k-h

On Sat, Apr 11, 2026 at 02:27:14PM +0200, Greg Kroah-Hartman wrote:
> On Sat, Apr 11, 2026 at 12:16:39PM +0000, Sidong Yang wrote:
> > On Thu, Apr 09, 2026 at 07:25:23AM +0200, Greg Kroah-Hartman wrote:
> > > On Wed, Apr 08, 2026 at 01:59:57PM +0000, Sidong Yang wrote:
> > > > This series introduces Rust abstractions for io_uring commands
> > > > (`IORING_OP_URING_CMD`) and wires them up to the miscdevice framework,
> > > > allowing Rust drivers to handle io_uring passthrough commands.
> > > > 
> > > > The series is structured as follows:
> > > > 
> > > > 1. Add io_uring C headers to Rust bindings.
> > > > 2. Zero-init pdu in io_uring_cmd_prep() to avoid UB from stale data.
> > > > 3. Core io_uring Rust abstractions (IoUringCmd, QueuedIoUringCmd,
> > > >    IoUringSqe, UringCmdAction type-state pattern).
> > > > 4. MiscDevice trait extension with uring_cmd callback.
> > > > 5. Sample demonstrating async uring_cmd handling via workqueue.
> > > > 
> > > > The sample completes asynchronously using a workqueue rather than
> > > > `io_uring_cmd_complete_in_task()`.  The latter is primarily needed
> > > > when completion originates from IRQ/softirq context (e.g. NVMe),
> > > > whereas workqueue workers already run in process context and can
> > > > safely call `io_uring_cmd_done()` directly.  A Rust binding for
> > > > `complete_in_task` can be added in a follow-up series.
> > > > 
> > > > Copy-based `read_pdu()`/`write_pdu()` are kept instead of returning
> > > > `&T`/`&mut T` references because the PDU is a `[u8; 32]` byte array
> > > > whose alignment may not satisfy `T`'s requirements.
> > > 
> > > Samples are great and all, but I would really like to see a real user of
> > > this before adding any more miscdev apis to the kernel.  Can you submit
> > > this as a series that also adds the driver that needs this at the same
> > > time?
> > 
> > Hi Greg,
> > 
> > Thank you for the review.
> > 
> > We have an out-of-tree C driver at Furiosa AI for our AI inference
> > accelerator that uses uring_cmd.  This is our primary motivation for
> > these abstractions.
> > 
> > We are considering upstreaming the driver and porting parts of it to
> > Rust using these abstractions.  If we were to upstream the driver,
> > would it need to be based on the accel subsystem (DRM)?  Or would a
> > standalone PCI driver approach also be acceptable?
> 
> Yes, it must use the accel subsystem as that is the correct api for it.

Thanks for the clarification.

I will proceed with this uring_cmd Rust abstraction patch as is. Moving 
forward with our AI accelerator driver, I will look into implementing it 
using the accel subsystem and work on creating the necessary Rust 
abstractions for it.

Since I am planning to adopt the accel subsystem, could you share some 
insights on the main benefits it provides for AI accelerators, or point me 
to any future roadmap/plans for the subsystem? This would be very helpful 
for my design and implementation.

Thanks,
Sidong

> 
> thanks,
> 
> greg k-h

On Wed, Apr 15, 2026 at 12:36:05AM +0900, Sidong Yang wrote:
> > Yes, it must use the accel subsystem as that is the correct api for it.
> 
> Thanks for the clarification.
> 
> I will proceed with this uring_cmd Rust abstraction patch as is. Moving 
> forward with our AI accelerator driver, I will look into implementing it 
> using the accel subsystem and work on creating the necessary Rust 
> abstractions for it.

Great.

> Since I am planning to adopt the accel subsystem, could you share some 
> insights on the main benefits it provides for AI accelerators, or point me 
> to any future roadmap/plans for the subsystem? This would be very helpful 
> for my design and implementation.

It is the common api for all accelerator drivers that you must use if
you wish to have a Linux driver for this type of hardware.  There should
be documentation in the kernel subsystem to read, and of course, there
are existing drivers using the api already.  If you have specific
questions about the api, please ask on that mailing list.

thanks,

greg k-h