Polling on an io_uring file descriptor

Polling on an io_uring file descriptor

[Drew DeVault]

I would like to poll on an io_uring file descriptor to be notified when
CQE's are available, either via poll(2) or IORING_OP_POLL_ADD. This
doesn't seem to work on 5.10. Is this feasible to add support for?

Re: Polling on an io_uring file descriptor

[Drew DeVault]

I found IOURING_REGISTER_EVENTFD, which does what I need. Pardon the
noise.

Re: Polling on an io_uring file descriptor

[Pavel Begunkov]

On 10/20/21 10:21, Drew DeVault wrote:
> I would like to poll on an io_uring file descriptor to be notified when
> CQE's are available, either via poll(2) or IORING_OP_POLL_ADD. This
> doesn't seem to work on 5.10. Is this feasible to add support for?

Not a canonical way, but both should work (POLLIN for CQEs).
Do you have a simple test case for us to reproduce?

-- 
Pavel Begunkov

Re: Polling on an io_uring file descriptor

[Drew DeVault]

On Wed Oct 20, 2021 at 12:15 PM CEST, Pavel Begunkov wrote:
> Not a canonical way, but both should work (POLLIN for CQEs).
> Do you have a simple test case for us to reproduce?

Hm, no, I cannot. I must have faced another bug, I was not able to
produce a minimal test case and my attempt to reproduce my earlier bug
in a larger test case was not succesful.

One issue which remains is that attempting to use REGISTER_FILES on
io_uring A with io_uring B's file descriptor returns EBADF. I saw a
comment in the kernel source explaining this, but it's a bit contrived
and the error case is not documented.

Re: Polling on an io_uring file descriptor

[Pavel Begunkov]

On 10/20/21 12:44, Drew DeVault wrote:
> On Wed Oct 20, 2021 at 12:15 PM CEST, Pavel Begunkov wrote:
>> Not a canonical way, but both should work (POLLIN for CQEs).
>> Do you have a simple test case for us to reproduce?
> 
> Hm, no, I cannot. I must have faced another bug, I was not able to
> produce a minimal test case and my attempt to reproduce my earlier bug
> in a larger test case was not succesful.

Sounds like polling is ok, let us know if there is any problem

> 
> One issue which remains is that attempting to use REGISTER_FILES on
> io_uring A with io_uring B's file descriptor returns EBADF. I saw a
> comment in the kernel source explaining this, but it's a bit contrived
> and the error case is not documented.

Surely should be updated if not mentioned

-- 
Pavel Begunkov

Re: Polling on an io_uring file descriptor

[Drew DeVault]

On Wed Oct 20, 2021 at 1:58 PM CEST, Pavel Begunkov wrote:
> > One issue which remains is that attempting to use REGISTER_FILES on
> > io_uring A with io_uring B's file descriptor returns EBADF. I saw a
> > comment in the kernel source explaining this, but it's a bit contrived
> > and the error case is not documented.
>
> Surely should be updated if not mentioned

That, or the constraint removed? The reasoning is a bit obscure and I
suspect that this case could be made possible.

Re: Polling on an io_uring file descriptor

[Drew DeVault]

On Wed Oct 20, 2021 at 2:00 PM CEST, Drew DeVault wrote:
> > Surely should be updated if not mentioned
>
> That, or the constraint removed? The reasoning is a bit obscure and I
> suspect that this case could be made possible.

So I dug into this a bit more, and the constraint seems to be to avoid a
reference loop when CONFIG_UNIX=n. I grepped Google and SourceGraph for
"CONFIG_UNIX=n" and only found two kernel configs with Unix sockets
disabled, neither of which had io_uring enabled. Given the rather
arbitrary restriction on registering io_urings with each other, and the
apparent absence of a use-case for io_uring without Unix sockets, can we
just require CONFIG_UNIX for io_uring and remove the limitation?

Re: Polling on an io_uring file descriptor

[Pavel Begunkov]

On 10/22/21 08:59, Drew DeVault wrote:
> On Wed Oct 20, 2021 at 2:00 PM CEST, Drew DeVault wrote:
>>> Surely should be updated if not mentioned
>>
>> That, or the constraint removed? The reasoning is a bit obscure and I
>> suspect that this case could be made possible.
> 
> So I dug into this a bit more, and the constraint seems to be to avoid a
> reference loop when CONFIG_UNIX=n. I grepped Google and SourceGraph for
> "CONFIG_UNIX=n" and only found two kernel configs with Unix sockets
> disabled, neither of which had io_uring enabled. Given the rather
> arbitrary restriction on registering io_urings with each other, and the
> apparent absence of a use-case for io_uring without Unix sockets, can we
> just require CONFIG_UNIX for io_uring and remove the limitation?

It's potentially problematic, even now we have a couple of other
spots relying on it. Is there a good reason why it's needed?

-- 
Pavel Begunkov

Re: Polling on an io_uring file descriptor

[Drew DeVault]

On Fri Oct 22, 2021 at 11:49 AM CEST, Pavel Begunkov wrote:
> It's potentially problematic, even now we have a couple of other
> spots relying on it. Is there a good reason why it's needed?

Yes, I have an application which uses one io_uring to manage a second
io_uring. I can skip registering the fd (current approach) or I can use
a different mechanism for managing the second uring (e.g. poll), but it
seems awkward and poorly justified that this invariant would exist.