Re: [PATCH] coda: file count cannot be used to discover last close

[Al Viro <viro@ftp.linux.org.uk>]

On Fri, Jul 20, 2007 at 12:10:00AM -0400, Jan Harkes wrote:
> I will try to find a clean way to block the close syscall until fput
> drops the last reference. However I realize that such an implementation
> would not be acceptable for other file systems, and there are some
> interesting unresolved details such as 'which close is going to be the
> last close'.

Simply impossible.

	fd = open(...);
	fd2 = dup(fd);
	....
	close(fd2);  <-- deadlock
	close(fd);

Or
	fd = open(...);
	p = mmap(..., fd, ...);
	close(fd);  <-- deadlock
	...
	munmap(p, ...);

The problem is that you are mixing two different operations:
	* closing descriptor: descriptor doesn't refer to this opened file
anymore.  Can be done by close(), can be done by dup2(), can be done by
fcntl() analog of dup2(), can be done by execve(), can be done by exit().
And can be done by death-by-signal.
	* closing opened file: no references (including descriptors) exist
anymore, no IO of any kind will be done on that IO channel.  Can happen
when descriptor gets closed, can happen when mapping gets destroyed (munmap,
etc.), can happen when SCM_RIGHTS datagram gets destroyed (including the
garbage collection), can happen when any syscall on that file finishes
after another thread has closed descriptor passed to that syscall, etc.

	You _can't_ expect the errors from the latter to be reliably
passed to some process; for one thing, many files can get closed by
single system call (e.g. closing an AF_UNIX socket with pending SCM_RIGHTS
datagrams will flush those datagrams, dropping references to files we
tried to pass via them).

	Why does CODA need special warranties in that area, anyway?
Related question: does fsync() force the writeback?