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

Rich Felker (2026-09-13 23:53 Europe/Helsinki):

On Sun, Sep 13, 2026 at 10:38:14PM +0300, Mikko Rantalainen wrote:

quoted

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.

This patch is about implementing the second option to be compatible with
both POSIX.1-2024 and real-world applications.

...

I don't think there is serious concern about userspace regressions
making this change. It would not be changing the meaning of any
existing result code or adding a new error condition applications need
to be aware of (like the EINPROGRESS mess).

But I'm also not sure how helpful the change would be. It's already
possible to patch this up in userspace, and as you noted, we already
do that in musl and so does Bionic. So the main practical effect of
this change would be just forcing the right behavior on glibc systems
even when glibc doesn't want to fix it. Maybe that's a good idea? I'm
not sure. I think it would be best to have everyone on the same page
that this should be fixed, with both glibc fixing it so it's right on
old-kernel/new-glibc, and the kernel fixing it so it's right on
new-kernel/old-glibc. That would also avoid hard feelings from a
unilateral action perceived as dictatorial.

I think there are two important questions:


(1) What is the caller truly expected to do for EINTR? They cannot
retry which would be the typical response to EINTR.

(2) If caller cannot retry because file was already closed, can caller
have any valuable information from EINTR return instead of success?
I think it's pretty safe assumption that success from close() would
be handled correctly by the caller.


I'm currently thinking that the answer to (1) is "???" and answer to
(2) is best you can do is to log "Some unknown action interrupted
some unknown background process while closing file XYZ, pretending
everything went well." because anything else would assume some
specific implementation of close() on Linux.

As I see it, the fact that avoiding EINTR return value when the file
is already closed fixing POSIX.1-2024 compatibility and glibc is just
a bonus for a change that makes sense otherwise, too.

-- 
Mikko