Re: kern/58916: timerfd(2) claims ready for write

["Taylor R Campbell via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/58916; it has been noted by GNATS.

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: Robert Elz <kre%NetBSD.org@localhost>
Cc: gnats-bugs%NetBSD.org@localhost, netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/58916: timerfd(2) claims ready for write
Date: Thu, 19 Dec 2024 14:15:01 +0000

 > Date: Thu, 19 Dec 2024 19:49:40 +0700
 > From: Robert Elz <kre%munnari.OZ.AU@localhost>
 > 
 >     Date:        Thu, 19 Dec 2024 02:39:17 +0000
 >     From:        Taylor R Campbell <campbell%mumble.net@localhost>
 >     Message-ID:  <20241219023918.2023460BB5%jupiter.mumble.net@localhost>
 > 
 >   | select(2) returns nonwritable if asked about the reader side of a
 >   | pipe (and vice versa, nonreadable if asked about the writer side of a
 >   | pipe).  Is that a bug?
 > 
 > Perhaps - I assume that also applies to any fd open O_WRONLY or O_RDONLY
 > with select/poll used for the other direction.   In practice I'm not
 > sure it matters, as real code just doesn't do things like this, code
 > doesn't ask when it can write to a fd which doesn't support write()
 > there's no point.
 
 It's not limited to O_WRONLY and O_RDONLY, or the read-only and
 write-only sides of a pipe.
 
 I tested with a disconnected stream-type socket and got the same
 result: read and write don't hang (they fail immediately with
 ENOTCONN, rather than EBADF), but select doesn't report them readable
 or writable.
 
 I checked some input-only devices too like wskbd and wsmouse, and they
 too never return POLLOUT|POLLWRNORM even though write would fail
 immediately with ENODEV.
 
 I think if we want select and poll to guarantee claiming
 readable/writable if a read or write would return immediately, we have
 a lot of work to do.
 
 Now it may be worthwhile to audit device poll routines for various
 types of bugs (like returning E* instead of POLL*), because they are
 often not very carefully written.
 
 But I don't think the particular behaviour you're asking for is useful
 when the underlying file object guarantees that read or write will
 _never_ work because the operation is nonsensical.