Re: [RFC PATCH 0/1] close(): stop exposing non-retryable EINTR

[Rich Felker <dalias@libc.org>]

On Sun, Sep 13, 2026 at 11:42:23PM +0100, Matthew Wilcox wrote:
> On Sun, Sep 13, 2026 at 10:38:14PM +0300, Mikko Rantalainen wrote:
> > However, currently Linux kernel will return EINTR in some cases for
> > close(). There is no good way for caller to recover from this case using
> > the original fd. Whatever action was actually interrupted cannot be
> > resumed or retried through this fd, because the fd has already been
> > consumed. Even worse, EINTR conventionally invites retrying an operation,
> > but retrying close() is unsafe: the same file descriptor number may
> > already refer to another file opened by another thread by the time
> > close() returns EINTR.
> > 
> > In addition, POSIX.1-2024 requires that if close() reports EINTR, the
> > descriptor must remain open. It also explicitly permits an interrupted
> > close() to return success after closing the descriptor.
> 
> I think any filesystem / device driver / ... which returns -EINTR from
> close() is broken.  There is one exception though -- if the signal is
> fatal.  It's like read()/write() being killable; if the signal is fatal,
> the task dies before it gets to see the errno.  So it doesn't matter.
> 
> So that's my preferred solution; track down the bad kernel code that's
> doing things in close() that are "interruptible" and convert them to
> "killable".

The traditional things that admit EINTR in close are bad NFS
implementations (which intentionally use interruptible instead of
killable because network flaky) and tape drives (which at least
historically performed rewinding as part of the close operation).

> We don't want SIGWINCH or SIGALRM interrupting close();
> that's just dumb.

You don't want a slow close blocking delivery of SIGALRM either.
Freezing the process during a long close is not the answer. The answer
is just getting rid of long close and having it behave properly as a
resource-handle-free-only operation and return immediately. But that's
a more invasive change than just replacing -EINTR with 0 if/when it
gets interrupted.

Rich