Date: 19 Mar 2002 00:01:59 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Alfred Perlstein <alfred@freebsd.org> Cc: Kris Kennaway <kris@obsecurity.org>, current@freebsd.org, fs@freebsd.org Subject: Re: panic: bwrite: buffer is not busy??? Message-ID: <xzphendlbtk.fsf@flood.ping.uio.no> In-Reply-To: <20020318223631.GA23014@elvis.mu.org> References: <20020317124958.A34008@xor.obsecurity.org> <xzpadt6r1xr.fsf@flood.ping.uio.no> <20020318061739.GB894@elvis.mu.org> <xzpvgbupdqa.fsf@flood.ping.uio.no> <20020318071623.GD894@elvis.mu.org> <20020318010245.A48956@xor.obsecurity.org> <xzp4rjep7m5.fsf@flood.ping.uio.no> <20020318143204.GA688@elvis.mu.org> <xzplmcpn8un.fsf@flood.ping.uio.no> <20020318223631.GA23014@elvis.mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Alfred Perlstein <alfred@freebsd.org> writes: > * Dag-Erling Smorgrav <des@ofug.org> [020318 08:23] wrote: > > Alfred Perlstein <alfred@freebsd.org> 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-fs" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?xzphendlbtk.fsf>