Date: Wed, 19 Jul 1995 11:24:51 -0700 From: Kirk McKusick <mckusick@McKusick.COM> To: Matt Dillon <dillon@blob.best.net> Cc: davidg@root.com, bugs@freebsd.org Subject: Re: possible ffs_vget() race condition Message-ID: <199507191824.LAA14283@chez.CS.Berkeley.EDU> In-Reply-To: Your message of "Wed, 19 Jul 1995 11:09:16 PDT." <199507191809.LAA07002@blob.best.net>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Wed, 19 Jul 1995 11:09:16 -0700
From: Matt Dillon <dillon@blob.best.net>
To: Kirk McKusick <mckusick@McKusick.COM>
Cc: davidg@root.com, bugs@freebsd.org
Subject: Re: possible ffs_vget() race condition
I've got some kernel printf()'s in the two critical code areas
along with my fix so by this time tomorrow I should know whether
the hole is getting hit.
Oh, there are also some pretty serious problems with the sysctl()
stuff... mainly with all the list traversals the sysctl()'s do
without locking and the copyout's inside the loops (which can
block, causing the list being traverse and most specifically the
'current' item to be ripped out from under sysctl())... I had
to stop using pstat -T because of the problem (it would crash
the machine every couple of hours). Since I absolutely need ps, I wound
up patched the proc stuff sysctl's adding a lock count to the process
structure which the exit/zombie code blocks on, but haven't
posted the patches because the whole sysctl thing really needs
a good going over to solve the problems.
-Matt
I do not believe that sysctl is the source of your problem.
For all data structures except the vnode table, it does a vslock
on the copyout buffer before starting the list traversal. Thus
the copyout cannot block. More likely your problems are arising
because the information that pstat is trying to report is coming
from /dev/kmem rather than through sysctl. Switching it to be
accessible from sysctl should solve your problem.
~Kirk
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199507191824.LAA14283>