From owner-freebsd-current@FreeBSD.ORG Sat May 22 13:30:12 2004 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4AB0B16A4CE for ; Sat, 22 May 2004 13:30:12 -0700 (PDT) Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id C1EE243D3F for ; Sat, 22 May 2004 13:30:11 -0700 (PDT) (envelope-from robert@fledge.watson.org) Received: from fledge.watson.org (localhost [127.0.0.1]) by fledge.watson.org (8.12.11/8.12.11) with ESMTP id i4MKU6Dw097255 for ; Sat, 22 May 2004 16:30:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Received: from localhost (robert@localhost)i4MKU6va097252 for ; Sat, 22 May 2004 16:30:06 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Sat, 22 May 2004 16:30:06 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: current@FreeBSD.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Why advisory locking in fdrop_locked() not vn_close()? X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 22 May 2004 20:30:12 -0000 fdrop_locked() is responsible for dropping a reference on a locked file descriptor, then optionally garbage collecting if it was the last reference. On the whole, it's really just a wrapper for fo_close(), which invokes the close method on the file operation vector. With one exception: if the file descriptor points at a vnode, then it calls VOP_ADVLOCK() on the vnode to release locks associated with the file descriptor. I'm looking at pushing down Giant into fo_close() so that close() called on pipes and sockets doesn't grab Giant, but it's the obvious obstacle. In my local work branch, I simply switch on the f_type to determine if I should grab Giant, but that's fairly undesirable. I'd like to push the VOP_ADVLOCK() call down into vn_close() and purge all VFS knowledge from fdrop_locked(), and then push Giant acquisition down into the fo_close() implementations (as needed). This would require pushing a file descriptor reference into fo_close(), which is not something the file descriptor API currently does for that method. It does, however, do this for several of the other file descriptor methods, so I'm not sure this change would represent a layering violation. Given that the locking code is at the VFS layer but that locks correspond to file descriptor level objects, it seems like some amount of layering mess is obligated anyway. I was wondering if anyone familiar with this code knows if there was a specific reason VOP_ADVLOCK() was placed at the file descriptor level rather than the fo_close() (vn_close()) level, other than the fact that the 'struct file *' simply wasn't passed down in existing code? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert@fledge.watson.org Senior Research Scientist, McAfee Research