Re: [PATCH v2 0/4] io_uring/uring_cmd: allow non-iopoll cmds with IORING_SETUP_IOPOLL

[Caleb Sander Mateos]

On Thu, Feb 19, 2026 at 5:30 AM Kanchan Joshi <joshi.k@xxxxxxxxxxx> 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