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

[Mikko Rantalainen <mikko.rantalainen@peda.net>]

Mikko Rantalainen (2026-09-14 12:07 Europe/Helsinki):
> ---
> retval = filp_flush(file, current->files);
> 
> WARN_ONCE(retval == -EINTR ||
>           retval == -ERESTARTSYS ||
>           retval == -ERESTARTNOINTR ||
>           retval == -ERESTARTNOHAND ||
>           retval == -ERESTART_RESTARTBLOCK,
>           "close: ->flush %ps returned interrupt error %d\n",
>           file->f_op->flush, retval);
> ---
> 
> That would leave the existing userspace ABI unchanged while making
> remaining offending implementations easier to find and fix.
> 
> I also considered retrying filp_flush() inside close(), but I don't
> think that can be done generically. ->flush() is not documented as
> safe to restart from the beginning after partial execution, and
> an interruptible wait could immediately encounter the same
> still-pending signal again. So fixing the interruptibility at the
> offending wait seems safer if the above invariant is indeed
> the intended one.

Another thing I noticed is that there are already several paths where
the kernel calls filp_close() and intentionally ignores its return value.

For example, close_files() does:

    filp_close(file, files);

without checking the result. The same is true for do_close_on_exec(),
and close_range() explicitly says:

    Currently, errors to close a given file descriptor are ignored.

So I don't think a ->flush() implementation can rely on returning EINTR
and having somebody retry the interrupted operation. There are valid
close paths where nobody will ever see that return value, even when the
process itself continues running.

This seems to strengthen Matthew's point: if some work performed by
->flush() is required for correctness, that work has to tolerate these
close paths without depending on userspace retry. Returning an
interruption result cannot be the recovery mechanism.

I'm therefore leaning towards treating an observable -EINTR/-ERESTART*
from ->flush() as suspicious in general, rather than just special-casing
the close(2) syscall. The fatal-signal case is harmless because the task
will not observe the result, but close-on-exec and close_range() show
that unobserved filp_close() errors are already part of normal operation
as well.

That also makes me think documenting the intended ->flush() contract
would be useful: if required close-time work must not depend on the
caller retrying filp_close(), that seems like an important invariant for
implementations to know.

What guarantees must file_operations::flush provide when its caller may
have no way to act on its return value?

In any case, I'm now thinking that returning EINTR for close() is a bug
when file descriptor is already freed. I think the only question is how
it should be solved. I initially thought it should just be mapped to
success. Maybe it should be logged as subsystem bug *and* mapped to
success for userspace instead?

-- 
Mikko