NetBSD Problem Report #55983

From dholland@netbsd.org  Tue Feb  9 01:12:15 2021
Return-Path: <dholland@netbsd.org>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits))
	(Client CN "mail.NetBSD.org", Issuer "mail.NetBSD.org CA" (not verified))
	by mollari.NetBSD.org (Postfix) with ESMTPS id 747011A9217
	for <gnats-bugs@gnats.NetBSD.org>; Tue,  9 Feb 2021 01:12:15 +0000 (UTC)
Message-Id: <20210209011214.C9C2784D6F@mail.netbsd.org>
Date: Tue,  9 Feb 2021 01:12:14 +0000 (UTC)
From: dholland@NetBSD.org
Reply-To: dholland@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: shortcomings in poll(2)
X-Send-Pr-Version: 3.95

>Number:         55983
>Category:       kern
>Synopsis:       shortcomings in poll(2)
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          doc-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Feb 09 01:15:00 +0000 2021
>Last-Modified:  Tue Feb 09 04:15:01 +0000 2021
>Originator:     David A. Holland
>Release:        NetBSD 9.99.80 (202002008)
>Organization:
>Environment:
System: NetBSD valkyrie 9.99.49 NetBSD 9.99.49 (VALKYRIE) #0: Fri Oct  2 15:00:22 EDT 2020  dholland@valkyrie:/y/objects/usrobj-amd64/sys/arch/amd64/compile/VALKYRIE amd64
Architecture: x86_64
Machine: amd64
>Description:

Some discussion in chat prompted me to look at poll(2) and it was
found wanting. I've improved it, but the following points remain (to
which I don't know the answers):

(1) Is the relationship between POLLIN/POLLOUT/POLLPRI and
POLLRDNORM/POLLWRNORM/POLLRDBAND the same in System V (and Linux) as
in NetBSD? In NetBSD these are synonyms, modulo POLLIN and POLLPRI
actually being distinct flags and thus being mishandled in a few
corner cases. If STREAMS causes System V to have more cases (which is
possibly consistent with the old wording of the man page, and hinted
at but not documented by the caveat at the end which I removed) they
should be documented as such.

(2) Is the behavior that sockets generate POLLRDNORM on hangup (like
with select) universal or NetBSD-specific? (Or somewhere in between?)
Either way it should be documented, because in the former case it's
somewhat unexpected and in the latter it's an important portability
consideration.

(3) Is ppoll different from pollts? The man page describes it as a
wrapper, but the arguments are the same and I thought they were the
equivalent.

(4) The previous version of the man page went out of its way to note
that you can't get POLLHUP and POLLWRNORM back together, and I kept
that in the new version, but what about POLLWRBAND or other I/O flags?
ISTM that a hung-up file should not select for any kind of read or
write, or return anything else either.

(5) We should document what you're supposed to do in response to
receiving POLLERR, since it's not obvious, nor is it obvious what is
safe to do at that point without blocking, but because none of this is
obvious I have no idea what to write.

(6) The "more useful" behavior described in COMPATIBILITY is...
NetBSD-specific? Shared with FreeBSD? Universal except for legacy SVR4
clones? This should be documented.

(7) It's nice to say that ppoll() appeared in NetBSD 10, but since
it's from Linux we should say which Linux version it first appeared
in.

>How-To-Repeat:
	n/a
>Fix:

Answer the questions here and I'll update the man page :-)

>Audit-Trail:
From: Valery Ushakov <uwe@stderr.spb.ru>
To: gnats-bugs@netbsd.org
Cc: 
Subject: Re: kern/55983: shortcomings in poll(2)
Date: Tue, 9 Feb 2021 07:11:54 +0300

 On Tue, Feb 09, 2021 at 01:15:00 +0000, dholland@NetBSD.org wrote:

 > (1) Is the relationship between POLLIN/POLLOUT/POLLPRI and
 > POLLRDNORM/POLLWRNORM/POLLRDBAND the same in System V (and Linux) as
 > in NetBSD? In NetBSD these are synonyms, modulo POLLIN and POLLPRI
 > actually being distinct flags and thus being mishandled in a few
 > corner cases. If STREAMS causes System V to have more cases (which is
 > possibly consistent with the old wording of the man page, and hinted
 > at but not documented by the caveat at the end which I removed) they
 > should be documented as such.

 The paper copy of SunOS 5.1 STREAMS Programmer's Guide that I have
 around says on page 6-2, in summary:

 POLLIN -        a message other than an M_PCPROTO
                 (uwe: i.e. same as POLLRDNORM|POLLRDBAND)

 POLLRDNORM -    a normal (non-priority) message

 POLRDBAND -     a priority message (band > 0)

 POLLPRI -       a high priority message (M_PCPROTO)

 POLLOUT -       the normal priority band is writable

 POLLWRNORM -    the same as POLLOUT

 POLLWRBAND -    a priority band greater than 0 of a queue downstream
                 exists and is writable


 > (2) Is the behavior that sockets generate POLLRDNORM on hangup (like
 > with select) universal or NetBSD-specific? (Or somewhere in between?)
 > Either way it should be documented, because in the former case it's
 > somewhat unexpected and in the latter it's an important portability
 > consideration.

 Here's a survey:

   http://www.greenend.org.uk/rjk/tech/poll.html


 > (3) Is ppoll different from pollts? The man page describes it as a
 > wrapper, but the arguments are the same and I thought they were the
 > equivalent.

 It's a literal wrapper b/c linux calls it ppoll, while we called it
 pollts.  See the thread started here:

   https://mail-index.netbsd.org/tech-userlevel/2020/05/25/msg012466.html

 kre@ says about ppoll that:

 | It has been (twice now) proposed to posix to be added (both still
 | pending, linked as duplicate reports) and my guess is is quite
 | likely to be added in the next version.

   https://mail-index.netbsd.org/tech-userlevel/2020/05/25/msg012475.html


 > (4) The previous version of the man page went out of its way to note
 > that you can't get POLLHUP and POLLWRNORM back together, and I kept
 > that in the new version, but what about POLLWRBAND or other I/O flags?
 > ISTM that a hung-up file should not select for any kind of read or
 > write, or return anything else either.

 I guess that follows the STREAM docs.  In the POLLHUP description it
 says that "[POLLHUP] and POLLOUT are mutually exclusive".  (Note that
 on Linux failed connect(2) is reported as POLLERR|POLLHUP|POLLOUT last
 time I checked)


 > (5) We should document what you're supposed to do in response to
 > receiving POLLERR, since it's not obvious, nor is it obvious what is
 > safe to do at that point without blocking, but because none of this is
 > obvious I have no idea what to write.

 STREAMS docs says that POLLERR means that a fatal error occured in one
 of the drivers associated with the stream and further syscalls will
 fail.


 > (6) The "more useful" behavior described in COMPATIBILITY is...
 > NetBSD-specific? Shared with FreeBSD? Universal except for legacy SVR4
 > clones? This should be documented.

 I'm not sure what that passage is supposed to mean.  There's POLLNVAL.


 -uwe

Home	PR Database Search