Currently, creating an io_uring with IORING_SETUP_IOPOLL requires all
requests issued to it to support iopoll. This prevents, for example,
using ublk zero-copy together with IORING_SETUP_IOPOLL, as ublk
zero-copy buffer registrations are performed using a uring_cmd. There's
no technical reason why these non-iopoll uring_cmds can't be supported.
They will either complete synchronously or via an external mechanism
that calls io_uring_cmd_done(), so they don't need to be polled.

Allow uring_cmd requests to be issued to IORING_SETUP_IOPOLL io_urings
even if their files don't implement ->uring_cmd_iopoll().

Use a new REQ_F_IOPOLL flag to track whether a request is using iopoll.
This makes the iopoll_queue opcode definition flag unnecessary.

The last commit removes an unnecessary IO_URING_F_IOPOLL check in
nvme_dev_uring_cmd() as NVMe admin passthru commands can be issued to
IORING_SETUP_IOPOLL io_urings now.

v2:
- Add REQ_F_IOPOLL request flag, remove redundant iopoll_queue
- Split IORING_OP_URING_CMD128 fix to a separate commit

Caleb Sander Mateos (4):
  io_uring: add REQ_F_IOPOLL
  io_uring: remove iopoll_queue from struct io_issue_def
  io_uring/uring_cmd: allow non-iopoll cmds with IORING_SETUP_IOPOLL
  nvme: remove nvme_dev_uring_cmd() IO_URING_F_IOPOLL check

 drivers/nvme/host/ioctl.c      |  4 ----
 include/linux/io_uring_types.h |  3 +++
 io_uring/io_uring.c            | 10 ++++------
 io_uring/opdef.c               | 10 ----------
 io_uring/opdef.h               |  2 --
 io_uring/rw.c                  | 11 ++++++-----
 io_uring/uring_cmd.c           |  9 ++++-----
 7 files changed, 17 insertions(+), 32 deletions(-)

-- 
2.45.2

On 2/19/2026 7:13 AM, Caleb Sander Mateos wrote:
> Currently, creating an io_uring with IORING_SETUP_IOPOLL requires all
> requests issued to it to support iopoll. This prevents, for example,
> using ublk zero-copy together with IORING_SETUP_IOPOLL, as ublk
> zero-copy buffer registrations are performed using a uring_cmd. There's
> no technical reason why these non-iopoll uring_cmds can't be supported.
> They will either complete synchronously or via an external mechanism
> that calls io_uring_cmd_done(), so they don't need to be polled.
> 
> Allow uring_cmd requests to be issued to IORING_SETUP_IOPOLL io_urings
> even if their files don't implement ->uring_cmd_iopoll().

For a moment I felt that series is going to change the user-facing 
behavior of IORING_SETUP_IOPOLL and therefore might require a 
documentation update [1].
But the change is limited to uring-cmd and that too for the files that 
don't implement ->uring_cmd_iopoll().


[1] The man page for IORING_SETUP_IOPOLL: "it is illegal to mix and 
match polled and non-polled I/O on an io_uring".

On Thu, Feb 19, 2026 at 5:30 AM Kanchan Joshi <joshi.k@samsung.com> wrote:
>
> On 2/19/2026 7:13 AM, Caleb Sander Mateos wrote:
> > Currently, creating an io_uring with IORING_SETUP_IOPOLL requires all
> > requests issued to it to support iopoll. This prevents, for example,
> > using ublk zero-copy together with IORING_SETUP_IOPOLL, as ublk
> > zero-copy buffer registrations are performed using a uring_cmd. There's
> > no technical reason why these non-iopoll uring_cmds can't be supported.
> > They will either complete synchronously or via an external mechanism
> > that calls io_uring_cmd_done(), so they don't need to be polled.
> >
> > Allow uring_cmd requests to be issued to IORING_SETUP_IOPOLL io_urings
> > even if their files don't implement ->uring_cmd_iopoll().
>
> For a moment I felt that series is going to change the user-facing
> behavior of IORING_SETUP_IOPOLL and therefore might require a
> documentation update [1].
> But the change is limited to uring-cmd and that too for the files that
> don't implement ->uring_cmd_iopoll().

Yes, in principle it should be possible to allow individual I/Os to
opt out of iopoll. I mentioned that as a future possibility in patch 1
("io_uring: add REQ_F_IOPOLL"). I'm wary of using up the last bit in
io_uring_sqe's 8-bit flags field for this possibly niche usecase. I
think it would probably make more sense to use an opcode-specific flag
field, e.g. rw_flags or attr_type_mask for read/write requests and
uring_cmd_flags for uring_cmd. Any opcodes that don't support iopoll
would implicitly opt out of it. I'd like to get some feedback about
the UAPI for opting out of iopoll and whether it even seems useful,
which is why I'm deferring it from this series.

>
>
> [1] The man page for IORING_SETUP_IOPOLL: "it is illegal to mix and
> match polled and non-polled I/O on an io_uring".

Good observation. I can definitely send a liburing PR to update the
man page if this series lands. FWIW, there are already several opcodes
allowed on IORING_SETUP_IOPOLL io_urings (IORING_OP_NOP,
IORING_OP_FILES_UPDATE, IORING_OP_MSG_RING, etc.) that don't actually
implement iopoll semantics. Basically any request that completes
synchronously is fine, but mixing iopoll requests with epoll-style
"poll" requests may be problematic.

Thanks,
Caleb