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

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    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