From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Chinner Subject: Re: [PATCH] coda: kill file_count abuse Date: Fri, 20 Jul 2007 16:03:47 +1000 Message-ID: <20070720060347.GE31489@sgi.com> References: <20070719214508.GA4482@lst.de> <20070719221559.GI8857@delft.aura.cs.cmu.edu> <20070720004534.GA31489@sgi.com> <20070720005316.GA21668@ftp.linux.org.uk> <20070720023601.GC31489@sgi.com> <20070720031631.GC21668@ftp.linux.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: David Chinner , Christoph Hellwig , akpm@osdl.org, linux-fsdevel@vger.kernel.org To: Al Viro Return-path: Received: from netops-testserver-3-out.sgi.com ([192.48.171.28]:38960 "EHLO relay.sgi.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1753260AbXGTGEF (ORCPT ); Fri, 20 Jul 2007 02:04:05 -0400 Content-Disposition: inline In-Reply-To: <20070720031631.GC21668@ftp.linux.org.uk> Sender: linux-fsdevel-owner@vger.kernel.org List-Id: linux-fsdevel.vger.kernel.org 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