From: Oleg Nesterov <oleg@redhat.com>
To: Mani Tofigh via B4 Relay <devnull+mt4022.columbia.edu@kernel.org>
Cc: Christian Brauner <brauner@kernel.org>,
Alexander Viro <viro@zeniv.linux.org.uk>, Jan Kara <jack@suse.cz>,
linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org,
tz2294@columbia.edu, stable@vger.kernel.org,
Mani Tofigh <mt4022@columbia.edu>
Subject: Re: [PATCH] pipe: keep per-write wakeups for EPOLLEXCLUSIVE consumers
Date: Thu, 12 Nov 2026 13:56:03 +0100 [thread overview]
Message-ID: <avW3Y_ea5v_zR48U@redhat.com> (raw)
In-Reply-To: <20261111-pipe-epollexclusive-wakeup-v1-1-0af6283e9fda@columbia.edu>
This probably needs more discussion... I will write another email.
But so far I think we don't really care.
On 11/11, Mani Tofigh via B4 Relay wrote:
>
> A task blocked in read() on a pipe can sleep while the pipe holds data,
> when an epoll(EPOLLEXCLUSIVE) watcher of the read end was added before
> it. The watcher's entry on ->rd_wait is exclusive and sits ahead of the
> reader, so a write into an empty pipe wakes only the watcher. The
> watcher reads without sleeping in anon_pipe_read() and doesn't pass the
> wakeup on. Since commit f1cebdec9739 ("pipe: only enable the extra
> wake_up(rd_wait) for EPOLLET consumers") the next writes into the
> non-empty pipe don't wake anyone anymore:
>
> Task E Task A Task C
> epoll_wait(ep, -1)
> /* EPOLLEXCLUSIVE */
> read(p[0])
> write(p[1], "1")
> /* wakes E only */
> write(p[1], "2")
> /* no wakeup */
> read(p[0], 1 byte)
> exit()
> /* still asleep, "2" is in the pipe */
Yes, in this case f1cebdec9739 ("pipe: only enable the extra wake_up(rd_wait)
for EPOLLET consumers") makes a difference.
However, this trivial test-case
#include <unistd.h>
#include <sys/epoll.h>
#include <sys/wait.h>
#include <assert.h>
#include <stdio.h>
int main(void)
{
int pfd[2], efd;
struct epoll_event evt = { .events = EPOLLIN | EPOLLEXCLUSIVE };
char c;
pipe(pfd);
efd = epoll_create1(0);
epoll_ctl(efd, EPOLL_CTL_ADD, pfd[0], &evt);
if (!fork()) {
epoll_wait(efd, &evt, 1, -1);
read(pfd[0], &c, 1);
printf("1st: %c\n", c);
return 0;
}
sleep(1);
if (!fork()) {
read(pfd[0], &c, 1);
printf("2nd: %c\n", c);
return 0;
}
sleep(1);
write(pfd[1], "12", 2);
assert(wait(NULL) > 0);
assert(wait(NULL) > 0);
return 0;
}
hangs even with this patch
+++ b/fs/pipe.c
@@ -749,6 +749,7 @@ pipe_poll(struct file *filp, poll_table *wait)
unlikely(!READ_ONCE(pipe->pseudo_edgetrigger)))
WRITE_ONCE(pipe->pseudo_edgetrigger, true);
+WRITE_ONCE(pipe->pseudo_edgetrigger, true);
/*
* Reading pipe state only -- no need for acquiring the semaphore.
*
which reverts f1cebdec9739.
The 2nd child sleeps in read(pfd[0]) forever even if the pipe is not empty.
So I am not sure we want to enforce another oddity in pipe_poll/read ...
Oleg.
prev parent reply other threads:[~2026-11-12 12:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-11-11 21:02 [PATCH] pipe: keep per-write wakeups for EPOLLEXCLUSIVE consumers Mani Tofigh via B4 Relay
2026-11-11 21:02 ` Mani Tofigh
2026-11-11 23:34 ` Oleg Nesterov
2026-11-12 10:26 ` Oleg Nesterov
2026-11-12 12:56 ` Oleg Nesterov [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=avW3Y_ea5v_zR48U@redhat.com \
--to=oleg@redhat.com \
--cc=brauner@kernel.org \
--cc=devnull+mt4022.columbia.edu@kernel.org \
--cc=jack@suse.cz \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mt4022@columbia.edu \
--cc=stable@vger.kernel.org \
--cc=tz2294@columbia.edu \
--cc=viro@zeniv.linux.org.uk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.