Rust blk-mq drivers currently cannot implement the `blk_mq_ops->poll`
callback: the Rust vtable hardcodes `poll: None`, and there is no safe
way for a driver to receive the borrowed hardware queue context or the
optional completion batch pointer that blk-mq passes to C drivers.

This small RFC series fills that abstraction gap and wires the new API
into `rnull` as a minimal in-tree user.

The core design choice is to keep the callback on borrowed blk-mq-owned
state instead of exposing raw pointers or synthesizing ownership in
Rust:

  fn poll(
      queue_data: ForeignBorrowed<'_, Self::QueueData>,
      hctx: &HwCtx,
      iob: Option<&IoCompBatch>,
  ) -> PollResult

`HwCtx` is a transparent borrowed wrapper over `struct blk_mq_hw_ctx`,
and `Option<&IoCompBatch>` models the nullable `struct io_comp_batch *`
argument directly. This keeps the Rust side aligned with the C lifetime
model of the callback, while still avoiding raw pointer handling in
drivers.

The return value is represented as a typed `PollResult` instead of a
bare `int`. The enum preserves blk-mq's semantics while making the Rust
side more self-descriptive:

- `PollResult::Completed(u32)` maps to a non-negative completion count.
- `PollResult::Stop` maps to the negative "stop polling" return.

The vtable wiring remains backward compatible: the callback is only
installed when `#[vtable]` reports `HAS_POLL`, so existing Rust blk-mq
drivers still get `poll: None` by default.

Patch 1 introduces the abstraction and hooks it into the blk-mq vtable.
Patch 2 implements a dummy `poll()` method in `rnull` returning
`PollResult::none()` as the minimal reference user.

Runtime validation summary
--------------------------

In addition to compiling the series in an out-of-tree build, the wiring
was validated at runtime in QEMU.

To exercise the Rust poll callback, I used a small out-of-tree helper
module as a test harness. The helper temporarily enabled a poll-capable
queue shape for an `rnull` device, submitted a `REQ_POLLED` bio, and
attached a kprobe directly to the queue's `mq_ops->poll` function
pointer. In the guest, the helper observed the Rust dummy poll callback
being invoked (`hits = 1`) and the polled bio completed successfully,
without deadlocks, crashes, or memory safety issues.

That helper is only test infrastructure and is not part of this RFC
series; it was used solely to provide a minimal "the VTABLE wiring
works" runtime proof for the new abstraction.

Any feedback on the design of the PollResult enum and the borrowing
strategy from hctx would be much appreciated.

Wenzhao Liao (2):
  rust: block: mq: safely abstract the poll callback
  block: rnull: wire up poll queues dummy callback

 drivers/block/rnull/rnull.rs       |   8 ++
 rust/kernel/block/mq.rs            |   2 +-
 rust/kernel/block/mq/operations.rs | 143 +++++++++++++++++++++++++++--
 3 files changed, 146 insertions(+), 7 deletions(-)

-- 
2.34.1

"Wenzhao Liao" <wenzhaoliao@ruc.edu.cn> writes:

> Rust blk-mq drivers currently cannot implement the `blk_mq_ops->poll`
> callback: the Rust vtable hardcodes `poll: None`, and there is no safe
> way for a driver to receive the borrowed hardware queue context or the
> optional completion batch pointer that blk-mq passes to C drivers.

Again, this is covered by the series at [1]. Please instruct your AI agent
to read that thread before submitting more patches.

Best regards,
Andreas Hindborg


[1] https://lore.kernel.org/rust-for-linux/20260216-rnull-v6-19-rc5-send-v1-0-de9a7af4b469@kernel.org/