Date: Wed, 27 Dec 2017 14:16:13 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 224615] [PATCH] kevent: EVFILT_READ returns EV_EOF on named pipe when it should not Message-ID: <bug-224615-8@https.bugs.freebsd.org/bugzilla/>
next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224615 Bug ID: 224615 Summary: [PATCH] kevent: EVFILT_READ returns EV_EOF on named pipe when it should not Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Keywords: patch Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: jan.kokemueller@gmail.com Keywords: patch Created attachment 189130 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=189130&action=edit patch for filt_piperead When connecting as a new reader to a named pipe after all previous writers have disconnected, EVFILT_READ currently returns EV_EOF. poll(2) was fixed a while ago so that it won't return POLLHUP in this case (at least since r238936). The attached patch brings the logic in EVFILT_READ in sync with poll(2) again. I wonder why the other side of the pipe is also checked in EVFILT_READ. Wouldn't it be enough to just check for EOF on the readers side? This would be consistent with sockets for example (where just SBS_CANTRCVMORE leads to EV_EOF). I've also attached a small patch to the pipepoll.c regression test that can be used to reproduce the issue. -- You are receiving this mail because: You are the assignee for the bug.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-224615-8>