From owner-freebsd-arch@FreeBSD.ORG Mon Jul 7 23:06:42 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 8E1CA106567E for ; Mon, 7 Jul 2008 23:06:42 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 26C4F8FC24 for ; Mon, 7 Jul 2008 23:06:41 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id E5E6146C7C; Mon, 7 Jul 2008 19:06:36 -0400 (EDT) Date: Tue, 8 Jul 2008 00:06:36 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Ken Smith In-Reply-To: <1215457201.89956.11.camel@neo.cse.buffalo.edu> Message-ID: <20080708000132.K63144@fledge.watson.org> References: <48714866.906912CC@verizon.net> <20080707000313.P56885@fledge.watson.org> <1215457201.89956.11.camel@neo.cse.buffalo.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Sergey Babkin Subject: Re: Proposal: a revoke() system call X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Jul 2008 23:06:42 -0000 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