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

[Ming Lei]

On Fri, Feb 20, 2026 at 09:47:38AM -0800, Caleb Sander Mateos wrote:
> On Fri, Feb 20, 2026 at 8:31 AM Ming Lei <ming.lei@xxxxxxxxxx> wrote:
> >
> > On Fri, Feb 20, 2026 at 08:22:29AM -0800, Caleb Sander Mateos wrote:
> > > On Fri, Feb 20, 2026 at 8:11 AM Ming Lei <ming.lei@xxxxxxxxxx> wrote:
> > > >
> > > > On Fri, Feb 20, 2026 at 07:55:33AM -0800, Caleb Sander Mateos wrote:
> > > > > On Fri, Feb 20, 2026 at 6:25 AM Ming Lei <ming.lei@xxxxxxxxxx> wrote:
> > > > > >
> > > > > > On Thu, Feb 19, 2026 at 10:22:23AM -0700, 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.
> > > > > >
> > > > > > For sync uring command, it is fine to support for IOPOLL.
> > > > > >
> > > > > > However, there are async uring command, which may be completed in irq
> > > > > > context, or in multishot way, at least the later isn't supported in
> > > > > > io_do_iopoll() yet.
> > > > >
> > > > > Can you describe the issues you envision in more detail?
> > > >
> > > > Basically IOPOLL doesn't support multishot request yet.
> > > >
> > > > For example, when io_uring_mshot_cmd_post_cqe() is called and new cqe is
> > > > queued, it can't be found from io_iopoll_check()<-io_uring_enter(IORING_ENTER_GETEVENTS).
> > >
> > > I don't think that's a new issue, though. You're right that
> > > io_uring_mshot_cmd_post_cqe() assumes a non-REQ_F_IOPOLL request, so
> > > it's up to the ->uring_cmd() implementation to ensure that (which ublk
> > > already does). Since ublk's struct file_operations don't provide
> > > ->uring_cmd_iopoll(), any ublk uring_cmds issued to an
> > > IORING_SETUP_IOPOLL io_uring won't have REQ_F_IOPOLL set, so
> > > io_uring_mshot_cmd_post_cqe() should work just fine.
> >
> > Please look in the following way:
> >
> > 1) without patch of `io_uring/uring_cmd: allow non-iopoll cmds with IORING_SETUP_IOPOLL`,
> > multishot command submission can't succeed
> >
> > 2) with patch of "io_uring/uring_cmd: allow non-iopoll cmds with IORING_SETUP_IOPOLL", people
> > may see hang forever in io_uring_enter() if multishot command is submitted
> > in context IORING_SETUP_IOPOLL.
> 
> Okay, I see what you mean. If ctx->iopoll_list is nonempty and a
> non-REQ_F_IOPOLL request posts a completion without going through task
> work, io_iopoll_check() won't check for CQEs already posted outside of
> iopoll. I think it should be simple enough to check for CQEs
> unconditionally in the io_iopoll_check() loop.

Yeah, it shouldn't be hard to deal with.

Thanks,
Ming