Hi Mikko, > Date: 2026-09-14 09:36:58+0300 > From: Mikko Rantalainen > > Rich Felker (2026-09-13 23:53 Europe/Helsinki): > > On Sun, Sep 13, 2026 at 10:38:14PM +0300, Mikko Rantalainen wrote: > >> 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. There's one thing a caller might do: Let's say I have a program doing a backup, and close(2) reports EINTR. I might decide that I don't trust any of what happened, and start the backup again from scratch. Of course, I should have sync(2)ed before calling close(2). So this should be a non-issue in the first place. This is the one thing that makes me think it might be better to keep close(2) broken: it would be a reminder that people should flush everything before calling close(2) if they care about their files. Have a lovely day! Alex > > > 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 > --