close(2) failure cases (was: some fixes to musl)

[Vasiliy Kulikov <segoon@openwall.com>]

Rich,

On Thu, Jul 21, 2011 at 14:21 -0400, Rich Felker wrote:
> > I wonder what is the Right Way to handle close() failures in generic
> > case.
> 
> I think 99% of them are complete non-issues. The whole idea that close
> can fail (for reasons other than EBADF) is a misdesign, but it can
> generally only happen for odd devices or NFS (which is broken in many
> more fundamental ways anyway). It certainly can't fail for terminal
> devices, pipes, sockets, directories, etc. which are the only places
> libc needs it.

I've looked at some Linux code related to close().  It may fail iff
file_ops->flush() is not NULL, and close() fails iff ->flush() fails.

So, as the following files don't implement ->flush, they cannot fail on
close():

* tty
* pipe
* sockets (all families)
* some classic devices: full, null, zero, mem, kmem

I cannot say something for sure for directories.  However, NFS'
implementation doesn't implement it => close() cannot fail.  (The
comment in the code says all directories ops are synchronous.)

close() may fail on NFS regural files.  As there is API to work with
/etc/* files, and / can be NFS mount point, it's good to check for
close() (and all other syscalls) failures on such files (whether write()
is actually succeeded).

Even if close() fails, the fd is freed.  So fd leakage is impossible.


As musl is Linux specific libc, you're free to rely on Linux specific
restrictions/features.  However, I don't know whether close()
implementation is guaranteed to be errorless for these types of files.
If no, it may be changed in the future by introducing some new feature
(and it will not break POSIX as POSIX explicitly defines close()
failure possibility).  It's very unlikely though, as breaking tons of
programs relying on implicit Linux behaviour is not encouraged by Linus.


Thanks,

-- 
Vasiliy