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

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> 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.