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

[Rich Felker]

On Thu, Sep 17, 2026 at 10:03:36AM -0700, Andy Lutomirski wrote:
> On Thu, Sep 17, 2026 at 3:37 AM Mikko Rantalainen
> <mikko.rantalainen@xxxxxxxx> wrote:
> >
> > On 9/17/26 02:16, Andy Lutomirski wrote:
> > > On Mon, Sep 14, 2026 at 2:44 AM Mikko Rantalainen
> > > <mikko.rantalainen@xxxxxxxx> wrote:
> > >
> > >> NFS and devices make the question more interesting, though. Some
> > >> implementations put meaningful state transitions into their close path.
> > >> Tape devices are an obvious historical example: depending on the
> > >> device/mode, close may write filemarks, flush tape buffers, rewind, etc.
> > >> Those operations are not necessarily replaceable by fsync() before
> > >> close().
> > >
> > > I realize this would be complex and maybe a can of worms, but maybe we
> > > should have a new improved syscall here.  close() is indeed deeply
> > > problematic.
> > >
> > > On the one hand, we have the actual task of closing an fd in the sense
> > > of removing it from the table.  This should really be doable without
> > > blocking or without side effects (except possibly for zapping
> > > old-style POSIX locks -- it doesn't really make sense to be able to
> > > close all fds to a file while still keeping it locked, especially
> > > since we report the pid of the lock-holding process).
> > >
> > > On the other hand, close has actual *meaningful* effects, many of
> > > which you've mentioned in your email.  IMO it would be really nice to
> > > be able to explicitly *do* those effects separately from closing the
> > > fd, maybe even asynchronously via io_uring.
> > >
> > > Would it be so bad to have a new operation to do (possibly with
> > > moderately fine control) the close work and another one to just
> > > release fd- and process-associated locks and drop the fd?
> >
> > I think introducing yet another syscall would be bad replacement
> > for the *inability to decide the exact semantics* we want to use for
> > the current syscalls, especially close().
> >
> > It's pretty clear that close() is poorly defined right now. The only
> > thing that we know for sure is that it releases the file descriptor
> > and in case of Linux, this happens for sure unless EBADF is returned.
> 
> I think I mostly agree with your analysis except that I really don't
> like the ENOSPC.  The kernel actually has the ability to commit to
> having space for pending writes on an fd *without syncing*, then I
> think that capability should be expose to userspace.  fsync is a
> pretty poor alternative for code that just wants to make sure that, in
> the absence of a bug, crash or physical failure, the data won't be
> lost.

Yes, if close() can give ENOSPC, that's indicative of a bug in
write(). I think the problem is everyone likes their bad NFS
implementations cutting corners to be fast...

Rich