From owner-freebsd-current Mon Mar 18 15: 2:44 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 BAF7837B416; Mon, 18 Mar 2002 15:02:01 -0800 (PST) Received: by flood.ping.uio.no (Postfix, from userid 2602) id 37C2F5346; Tue, 19 Mar 2002 00:02:00 +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> <20020318010245.A48956@xor.obsecurity.org> <20020318143204.GA688@elvis.mu.org> <20020318223631.GA23014@elvis.mu.org> From: Dag-Erling Smorgrav Date: 19 Mar 2002 00:01:59 +0100 In-Reply-To: <20020318223631.GA23014@elvis.mu.org> Message-ID: Lines: 24 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: > * Dag-Erling Smorgrav [020318 08:23] wrote: > > Alfred Perlstein writes: > > > I think you're right, I'm pretty sure the fix is basically moving > > > the p->p_fd = NULL to after the closef will fix things [...] > > There will still be a race... > Are you sure? :) Almost, though I think the window will be much smaller than it is now. The only way I see of avoiding it alltogether is to protect p->p_fd and its mutex with allproc_lock (IOW, destroy the table as the last thing you do before zombifying the process) > Btw, is there a way to easily reproduce this bug? No, it's a race condition, which makes it hard to trigger on purpose. The problem with your patch is that *every* place in the kernel that calls FILEDESC_LOCK needs to first acquire the proc lock and check if p->p_fd is NULL. 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