From owner-freebsd-current Mon Mar 18 1: 0:57 2002 Delivered-To: freebsd-current@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 6F1D137B404; Mon, 18 Mar 2002 01:00:46 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 28C2E5346; Mon, 18 Mar 2002 10:00:43 +0100 (CET) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: Alfred Perlstein Cc: Kris Kennaway , current@FreeBSD.org, fs@FreeBSD.org Subject: Re: panic: bwrite: buffer is not busy??? References: <20020317124958.A34008@xor.obsecurity.org> <20020318061739.GB894@elvis.mu.org> <20020318071623.GD894@elvis.mu.org> From: Dag-Erling Smorgrav Date: 18 Mar 2002 10:00:42 +0100 In-Reply-To: <20020318071623.GD894@elvis.mu.org> Message-ID: Lines: 42 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.1 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Alfred Perlstein writes: > It was untested. :) I'm sure you can fix it, I've got to get some > sleep, let me know if it works for you. Sure. Turns out the patch doesn't work, because closef() needs p->p_fd to be valid. This is really tricky; you either need to protect *every* access to p->p_fd with the proc lock, or figure out some other way of handling things. fdfree() is currently used in a handful of places: - in kern_exec.c, an fdcopy() / fdfree() combo is used to unshare the file table in case it is shared (vfork()); this is a waste of time unless the table actually *is* shared, which is easy to check. This could replaced by a single call to a new function, fdunshare(), which checks the reference count and does an fdcopy() if it is greater than 1. - in kern_exit.c, fdfree() is used to close all file descriptors and destroy the table before turning the process into a zombie (this is the one that's giving us trouble). This could be handled by an fdclear() function, with the actual destruction of the filedesc and its mutex (performed by a new fddestroy() function?) left off until the last possible moment, after the process has been removed from the process table. - in kern_fork.c, one case where an fdcopy() / fdfree() combo is used to unshare the file table (see comment above about fdunshare()) and one case where fdfree() / fdinit() is used to completely clear the file table (RFCFDG case). The latter could be handled by a new fdclear() function. - in vfs_aio.c, fdfree() is called once to destroy the aio daemon's file table, and twice to dereference the client's file table after it has been temporarily "borrowed" by the aio daemon. This code gives me a headache, for several reasons (one of which is a potential race condition similar to the one we're already seeing in kern_exit.c; another is its rather cavalier treatment of curproc) DES -- Dag-Erling Smorgrav - des@ofug.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message