[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <m11vrxprk6.fsf@fess.ebiederm.org>
Date: Sun, 12 Apr 2009 13:04:09 -0700
From: ebiederm@...ssion.com (Eric W. Biederman)
To: Jamie Lokier <jamie@...reable.org>
Cc: Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org, linux-pci@...r.kernel.org,
linux-mm@...ck.org, linux-fsdevel@...r.kernel.org,
Al Viro <viro@...IV.linux.org.uk>,
Hugh Dickins <hugh@...itas.com>, Tejun Heo <tj@...nel.org>,
Alexey Dobriyan <adobriyan@...il.com>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Alan Cox <alan@...rguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@...e.de>
Subject: Re: [RFC][PATCH 8/9] vfs: Implement generic revoked file operations
Jamie Lokier <jamie@...reable.org> 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 from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists