Proposal: a revoke() system call

[Robert Watson]

On Mon, 7 Jul 2008, Ken Smith wrote:

> On Mon, 2008-07-07 at 00:05 +0100, Robert Watson wrote:
>> You could achieve something of the same end by opening /dev/null and then 
>> dup2()'ing to the file descriptor you want to revoke, perhaps?
>
> I might be missing something but isn't this what the deadfs vnodeops are 
> for?

It's a little different, although similar.  When a vnode is deadfs'd, such as 
after a call to revoke(2)'s historic implementation, all open file descriptors 
on the file are invalidated.  I think that Sergey is suggesting semantics in 
which only the current file descriptor refering to the object is invalidated 
-- other independently acquired file descriptors in other processes would 
remain valid.

BTW, this does show up one of the potential semantic conflicts in the proposed 
new revoke behavior: suppose a TCP connection is opened, and two processes 
have references to the file descriptor for the connection.  One of those 
processes is multi-threaded, and has a blocking read(2) on the file descriptor 
in one thread, and calls close(2) from another thread.  Is the proposal to 
cancel in-progress I/O's against the file descriptor even though the 
connection isn't closing due to the further reference to the same descriptor 
in another process?  Solaris has a pretty complex infrastructure to support 
that sort of in-kernel cancellation -- the shutdown(2) behavior we have is 
fairly different in that it manipulates connection state to cancel outstanding 
I/O's, and would also affect the second process, rather than simply consumers 
on the one file descriptor.

Robert N M Watson
Computer Laboratory
University of Cambridge