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

["Robert Elz via gnats" <gnats-admin%NetBSD.org@localhost>]

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

From: Robert Elz <kre%munnari.OZ.AU@localhost>
To: Taylor R Campbell <riastradh%NetBSD.org@localhost>
Cc: Jason Thorpe <thorpej%me.com@localhost>, gnats-bugs%NetBSD.org@localhost,
        netbsd-bugs%NetBSD.org@localhost
Subject: Re: kern/58916: timerfd(2) claims ready for write
Date: Fri, 20 Dec 2024 00:42:10 +0700

     Date:        Thu, 19 Dec 2024 13:57:15 +0000
     From:        Taylor R Campbell <riastradh%NetBSD.org@localhost>
     Message-ID:  <20241219135721.0AF69855E1%mail.netbsd.org@localhost>
 
   | We can do that but I want to make sure we have a clear story for what
   | timerfd(2) _should_ be doing so we have a compelling argument that it
   | is a Python bug.
 
 In this case that should be easy ... since no-one apparently supports
 writing to a timerfd, there is no reason to test, in any way, that
 doing so fails, as no existing (python or other) code can possibly
 have a valid reason for attempting a write to a timerfd, but it is
 possible that some implementation might add a timerfd extension which
 would involve writing to one of them.
 
 Note that this doesn't mean that a kernel specific test for how
 timerfds work shouldn't test for attempting a write, and checking that
 the (system dependent) error is returned, if only so that no local
 change inadvertently alters how things work (eg: whether it is even
 possible to open a timerfd for writing, and if it is, what happens
 when a write is attempted) - but there is no reason at all for this
 to be connected to anything intended to be portable across systems.
 
   | Right now there's another part of the Python test suite that crashes
   | the kernel, and on closer inspection -- in the course of writing tests
   | to cover that case -- I'm not actually sure what the right thing is
   | there (PR 58914).
 
 Yes, that one looks like it ought to be fixed, and your patch looked like
 it was reasonable to me.   But I have never used a timerfd, so have no
 real way to know for sure what should happen.
 
 kre