From: Linus Torvalds <firstname.lastname@example.org> To: Michael Kerrisk-manpages <email@example.com>, Alexander Viro <firstname.lastname@example.org> Cc: David Howells <email@example.com>, Rasmus Villemoes <firstname.lastname@example.org>, Greg Kroah-Hartman <email@example.com>, Peter Zijlstra <firstname.lastname@example.org>, Nicolas Dichtel <email@example.com>, Ian Kent <firstname.lastname@example.org>, Christian Brauner <email@example.com>, firstname.lastname@example.org, "email@example.com" <firstname.lastname@example.org>, Linux API <email@example.com>, lkml <firstname.lastname@example.org> Subject: Re: Regression: epoll edge-triggered (EPOLLET) for pipes/FIFOs Date: Mon, 12 Oct 2020 12:25:44 -0700 [thread overview] Message-ID: <CAHk-=wig1HDZzkDEOxsxUjr7jMU_R5Z1s+v_JnFBv4HtBfP7QQ@mail.gmail.com> (raw) In-Reply-To: <CAKgNAkjMBGeAwF=2MKK758BhxvW58wYTgYKB2V-gY1PwXxrH+Q@mail.gmail.com> On Mon, Oct 12, 2020 at 11:40 AM Michael Kerrisk (man-pages) <email@example.com> wrote: > > Between Linux 5.4 and 5.5 a regression was introduced in the operation > of the epoll EPOLLET flag. From some manual bisecting, the regression > appears to have been introduced in > > commit 1b6b26ae7053e4914181eedf70f2d92c12abda8a > Author: Linus Torvalds <firstname.lastname@example.org> > Date: Sat Dec 7 12:14:28 2019 -0800 > > pipe: fix and clarify pipe write wakeup logic > > (I also built a kernel from the immediate preceding commit, and did > not observe the regression.) So the difference from that commit is that now we only wake up a reader of a pipe when we add data to it AND IT WAS EMPTY BEFORE. > The aim of ET (edge-triggered) notification is that epoll_wait() will > tell us a file descriptor is ready only if there has been new activity > on the FD since we were last informed about the FD. So, in the > following scenario where the read end of a pipe is being monitored > with EPOLLET, we see: > > [Write a byte to write end of pipe] > 1. Call epoll_wait() ==> tells us pipe read end is ready > 2. Call epoll_wait() [again] ==> does not tell us that the read end of > pipe is ready Right. > If we go further: > > [Write another byte to write end of pipe] > 3. Call epoll_wait() ==> tells us pipe read end is ready No. The "read end" readiness has not changed. It was ready before, it's ready now, there's no change in readiness. Now, the old pipe behavior was that it would wake up writers whether they needed it or not, so epoll got woken up even if the readiness didn't actually change. So we do have a change in behavior. However, clearly your test is wrong, and there is no edge difference. Now, if this is more than just a buggy test - and it actually breaks some actual application and real behavior - we'll need to fix it. A regression is a regression, and we'll need to be bug-for-bug compatible for people who depended on bugs. But if it's only a test, and no actual workflow that got broken, then it's just a buggy test. [ Adding Al to the participants, not because he has anything to do with this pipe change, but because he's been working on epoll cleanups, and I just want him to be aware of this thread. Al - Michael has a test program for this thing that may or may not be worth keeping in mind ] Linus
next prev parent reply other threads:[~2020-10-12 19:26 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-10-12 18:39 Michael Kerrisk (man-pages) 2020-10-12 19:25 ` Linus Torvalds [this message] 2020-10-12 19:28 ` Linus Torvalds 2020-10-12 20:30 ` Michael Kerrisk (man-pages) 2020-10-12 20:52 ` Linus Torvalds 2020-10-12 21:43 ` Randy Dunlap 2020-10-12 21:51 ` Michael Kerrisk (man-pages) 2020-10-12 22:30 ` Linus Torvalds 2020-10-13 9:47 ` Michael Kerrisk (man-pages)
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='CAHk-=wig1HDZzkDEOxsxUjr7jMU_R5Z1s+v_JnFBv4HtBfP7QQ@mail.gmail.com' \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --subject='Re: Regression: epoll edge-triggered (EPOLLET) for pipes/FIFOs' \ /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
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).