Re: [PATCH] coda: kill file_count abuse

[David Chinner <dgc@sgi.com>]

On Fri, Jul 20, 2007 at 04:16:31AM +0100, Al Viro wrote:
> On Fri, Jul 20, 2007 at 12:36:01PM +1000, David Chinner wrote:
> > To the context that dropped the last reference. It can't be
> > reported to anything else....
> 
> Oh, for fsck sake...
> 
> Send a datagram with SCM_RIGHTS in it.  Have all other references
> to these files closed.  Now have close(2) kill the socket that
> might eventually be used to receive the datagram.  Now, all these
> files are closed.  Tell me, which error value would you report
> to that caller of close() and how would it guess which files had
> those been?
>
> Consider munmap().  It can release the last reference to any number
> of files (mmap them in different places, then munmap the entire
> area).  Which error would you report?
>
> Consider exit(), for crying out loud.  You have a file opened.
> You fork a child.  You close the file in parent.  Child goes
> away.  Who do you report that stuff?

Yup, all good cases where we can't report an error.

OTOH, consider a single thread doing an open(), write(), close().
That's a case where we could report an error, and it's far, far more
common than any of the scenarios you list above.

Effectively, that is my point - it's the fput() calling context
that knows whether it can return a meaningful error or not.
And ->release being non-void implies that you can return
meaningful errors to the caller.

So either fput() needs to propagate errors or ->release() should
be void, right?

Cheers,

Dave.
-- 
Dave Chinner
Principal Engineer
SGI Australian Software Group