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

From
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Date
2026-03-13 15:52:35
Also in
linux-doc, linux-fsdevel, linux-kbuild, linux-kselftest, lkml, tools, workflows
Reply to
Sasha Levin, 2026-03-13
On Fri, Mar 13, 2026 at 11:09:16AM -0400, Sasha Levin wrote:
quoted hunk ↗ jump to hunk
+ * 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 :)
quoted hunk ↗ jump to hunk
+ *   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?

quoted hunk ↗ jump to hunk
+ *
+ *   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.

thanks,

greg k-h
Thread (38 messages) 38 messages, 8 authors, last reply 2026-04-08
Keyboard shortcuts
hback out one level
jnext message in thread / next series-diff position
kprevious message in thread / previous series-diff position
ldrill in
Escclose help / fold thread tree
?toggle this help