Re: [PATCH 6/9] kernel/api: add API specification for sys_close

[Sasha Levin <sashal@kernel.org>]

On Fri, Mar 13, 2026 at 04:52:30PM +0100, Greg Kroah-Hartman wrote:
>On Fri, Mar 13, 2026 at 11:09:16AM -0400, Sasha Levin wrote:
>> + * notes: This syscall has subtle non-POSIX semantics: the fd is ALWAYS closed
>> + *   regardless of the return value. POSIX specifies that on EINTR, the state
>> + *   of the fd is unspecified, but Linux always closes it. HP-UX requires
>> + *   retrying close() on EINTR, but doing so on Linux may close an unrelated
>> + *   fd that was reassigned by another thread. For portable code, the safest
>> + *   approach is to check for errors but never retry close().
>
>We don't care about HP-UX :)

Fair :) The original text was contrasting Linux's "always closed" behavior
with HP-UX. I'll just drop that reference.

>> + *   Error codes from the flush callback (EIO, ENOSPC, EDQUOT) indicate that
>> + *   previously written data may have been lost. These errors are particularly
>> + *   common on NFS where write errors are often deferred to close time.
>
>What flush callback?

This was referring to f_op->flush, which filp_flush() calls during close.

But you're right, that's internal plumbing. I'll reworded to describe the
behavior without referencing internal callbacks:

   Error codes like EIO, ENOSPC, and EDQUOT indicate that previously
   buffered writes may have failed to reach storage.

>> + *
>> + *   The driver's release() callback errors are explicitly ignored by the
>> + *   kernel, so device driver cleanup errors are not propagated to userspace.
>
>What "The driver" here?  release() callbacks aren't really relevant
>here.

The original text was noting that __fput() ignores the return value of
f_op->release(), so even if a driver's cleanup fails, userspace never
sees it via close(). But agreed, that's an internal implementation detail
not relevant to the syscall specification. Removed.

Thanks for the review!

-- 
Thanks,
Sasha