Re: [PATCH 0/1] pipe: only enable the extra wake_up(rd_wait) when epoll is actually used

On Fri, Jul 24, 2026 at 3:58 PM Oleg Nesterov <[email protected]> wrote:
>
> On 07/23, Oleg Nesterov wrote:
> >
> > OK, sashiko has some concerns
> >
> >       https://sashiko.dev/#/patchset/amIqmbbZx3NlzUsX%40redhat.com
>
> Let me quote:
>
>         Does skipping this wakeup for non-epoll consumers break io_uring?
>
>         Applications polling pipes via io_uring do not attach an eventpoll context,
>         so pipe->epoll_usage will be false. If a writer writes to an empty pipe,
>         io_uring receives the wakeup.
>
>         If the writer then writes a second chunk before the first is drained,
>         anon_pipe_write() observes was_empty == false and
>         pipe_get_epoll_usage() == false, skipping the waitqueue wakeup.
>
>         Could this cause io_uring to miss events and hang permanently, waiting
>         for a CQE that will never be emitted for the new data?
>
> and I am starting to think sashiko is right (damn as always ;) and this
> patch does affect/break io_uring.
>
> Jens, could you confirm? If yes, we need to update the comments in pipe.c
> (I've attached 1/1 at the end, so that you can see what this patch does)
>
> I know nothing about io_uring and io_uring/poll.c is not trivial to say at
> least ;) please check my understanding.
>
> It seems that IORING_OP_POLL_ADD / IORING_POLL_ADD_MULTI is edge-triggered
> by default! Like EPOLL_CTL_ADD / EPOLLET.
>
> This means that io_uring depends on the "nasty semantics" too, io_poll_wake()
> path should add the task work which calls io_req_post_cqe() every time the new
> data arrives, even if the pipe was not empty.
>

well io_uring could set the flag as well in that case? it does not
inherently mean random select and poll consumers definitely need this.