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

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".  We don't want SIGWINCH or SIGALRM interrupting close();
that's just dumb.