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 - To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
