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

[Taylor R Campbell <campbell%mumble.net@localhost>]

> Date: Thu, 19 Dec 2024 08:34:07 +0700
> From: Robert Elz <kre%munnari.OZ.AU@localhost>
> 
>     Date:        Wed, 18 Dec 2024 14:55:00 +0000 (UTC)
>     From:        campbell+netbsd%mumble.net@localhost
>     Message-ID:  <20241218145500.8B58E1A923B%mollari.NetBSD.org@localhost>
> 
>   | For a timerfd(2), select(2) returns writable if asked and poll(2)
>   | returns POLLOUT|POLLWRNORM if asked.  (Also POLLRDNORM if asked.)\
> 
> Seems reasonable to me.

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?

>   | In contrast, in Linux, select(2) never returns writable
> 
> I don't know what Linux does on writes, is it also:
> 
>   | Writing to a timerfd fails with EOPNOTSUPP,
> 
> If so, then I'd suggest Linux's poll/select has a bug.

Correction:

- On Linux, writing to a timerfd fails with EINVAL.
- On NetBSD, writing to a timerfd fails with EBADF (same as the reader
  side of a pipe).

>   | so it's not useful to claim writable.
> 
> Someone fails to understand the purpose of poll/select.   It isn't
> to inform the process that a read/write will succeed, it is to inform
> the process that a read/write will not hang.   There are too many possible
> results for select (which just returns 1 bit) in particular to be able
> to differentiate between different possible results (poll() possibly
> could, but doesn't really) - so there is no attempt to do that.

OK, but:

(a) Probably need to audit all the struct fileops and struct cdevsw
    *poll functions in tree if you want to enforce this -- and you'll
    have to change a lot of existing cases, I expect.

(b) Currently Linux is the `spec' for timerfd and we're deviating from
    that behaviour.

(c) timerfd-on-NetBSD is the only case of {pipe, timerfd, kqueue,
    ...}-on-{NetBSD, Linux} that I've found that behaves like this,
    where writes are nonsensical and immediately rejected but select
    returns writable.  (But I haven't done an exhaustive search.)

(This came up in Python's automatic tests of select on timerfds,
details in <https://gnats.netbsd.org/58914>.  Happy to revert the
change.  Mainly I just want to make sure these timer- and timerfd-
related paths are adequately exercised with clear automatic tests that
cover enough to avoid gratuitous application incompatibility and
kernel crashes.)