Re: kern/57703: kernel panic in eventfd_fop_close()

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

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

From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
To: paul%whooppee.com@localhost
Cc: gnats-bugs%NetBSD.org@localhost, thorpej%NetBSD.org@localhost
Subject: Re: kern/57703: kernel panic in eventfd_fop_close()
Date: Sat, 18 Nov 2023 20:45:43 +0000

 It looks like the problem is that the cv_wait_sig in eventfd_wait was
 interrupted by a signal, and nothing cleared efd_has_read_waiters.
 
 The only things that do clear efd_has_read_waiters are eventfd_wake
 and eventfd_fop_restart, but:
 
 1. eventfd_wake is only used when a read or write is in progress and a
    concurrent matching write or read is triggered -- not happening
    here, as far as I can tell; the pulseaudio process is just waiting
    and was woken by a signal.
 
 2. eventfd_fop_close is only used when a read or write is in progress
    and a concurrent close is triggered -- also not happening here, as
    far as I can tell; the read or write was woken by a signal, and
    _then_ (sequentially, not concurrently) the file was closed during
    process teardown.
 
 I think we should just nix efd_has_read/write_waiters, because
 cv_broadcast already has this micro-optimization built-in, and the
 assertion would need more bookkeeping to make it actually work.  We
 can just keep the efd_nwaiters == 0 assertion and it'll be fine.