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

[Andy Lutomirski]

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?

(Hmm, for OFD locks, it really does make sense to unlock when the OFD
goes away.  For old-style locks, maybe we want a way to release an fd
without dropping the lock if it's not the last reference to the
underlying file in the process.  But maybe specifying and implementing
that would be a nightmare.)

--Andy