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 <campbell%mumble.net@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 02:39:17 +0000

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