From mboxrd@z Thu Jan 1 00:00:00 1970 From: ebiederm@xmission.com (Eric W. Biederman) Subject: Re: [RFC][PATCH 8/9] vfs: Implement generic revoked file operations Date: Sun, 12 Apr 2009 13:04:09 -0700 Message-ID: References: <20090412185659.GE4394@shareable.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: Andrew Morton , linux-kernel@vger.kernel.org, linux-pci@vger.kernel.org, linux-mm@kvack.org, linux-fsdevel@vger.kernel.org, Al Viro , Hugh Dickins , Tejun Heo , Alexey Dobriyan , Linus Torvalds , Alan Cox , Greg Kroah-Hartman To: Jamie Lokier Return-path: In-Reply-To: <20090412185659.GE4394@shareable.org> (Jamie Lokier's message of "Sun\, 12 Apr 2009 19\:56\:59 +0100") Sender: owner-linux-mm@kvack.org List-Id: linux-fsdevel.vger.kernel.org Jamie Lokier writes: >> revoked_file_ops return 0 from reads (aka EOF). Tell poll the file is >> always ready for I/O and return -EIO from all other operations. > > I think read should return -EIO too. If a program is reading from a > /proc file (say), and the thing it's reading suddenly disappears, EOF > gives the false impression that it's read to the end of formatted data > from that file and it can process the data as if it's complete, which > is wrong. Good point EIO is the current read return value for a removed proc file. For closed pipes, and hung up ttys the read return value is 0, and from my reading that is what bsd returns after a sys_revoke. The reason I have f_op settable is because I never expected complete agreement on the return codes, and because it makes auditing and spotting this kind of thing easier. I guess I should make two variations on revoked_file_ops then. Say eof_file_ops, eio_file_ops. Identical except for their treatment of reads. Eric -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org