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=3D224615 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=3D189130&action= =3Dedit 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. --=20 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>