Date: 11 Dec 2001 18:30:30 +0100 From: Dag-Erling Smorgrav <des@ofug.org> To: Stefan.Esser@o-tel-o.de Cc: freebsd-gnats-submit@FreeBSD.org, fs@freebsd.org Subject: Re: kern/32681: Reproducable PANIC in -stable Message-ID: <xzpwuztu0jt.fsf@flood.ping.uio.no> In-Reply-To: <200112111500.fBBF04J48329@freefall.freebsd.org> References: <200112111500.fBBF04J48329@freefall.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Stefan.Esser@o-tel-o.de writes:
> In order to check for the presence of some process %PID%, nessusd performs an
> opendir("/proc/%PID%"), which can lead to a panic in fstafs(), if the
> corresponding process just finishes just before the call to fstatfs ...
Ah, OK, I see. First, if nessus needs to check for the existence of a
process with a given PID, it should kill(pid, 0) instead of relying on
procfs. Second, the problem seems to be insufficient locking -
possibly in pseudofs, but equally possibly in the VFS system. When a
process terminates, pseudofs automatically reclaims all vnodes
associated with it, which leads to an obvious race condition which can
only be avoided through proper locking.
Looking at the pseudofs code, it doesn't seem to be at fault. When
the process exits, pfs_exit() removes all vnodes associated with it
from pseudofs' vnode cache, and vgone()s them.
I'm starting to think that the race might be in namei(), actually -
since the namei() call from fstatfs() succeeds, it means namei() found
a vnode, but that vnode's v_mount is NULL, which means it's been
reclaimed, which can't happen if it's referenced (can it?), and
namei() is supposed to reference the vnode before it returns it. My
bet is that there is a small race between namei() finding a vnode and
referencing it, but I'm getting out of my depth. Does anybody else
have any ideas?
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?xzpwuztu0jt.fsf>