Date: Thu, 30 Aug 2001 19:30:44 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Mike Silbersack <silby@silby.com> Cc: John Baldwin <jhb@FreeBSD.ORG>, <cvs-all@FreeBSD.ORG>, <cvs-committers@FreeBSD.ORG> Subject: Re: RE: cvs commit: src/sys/kern init_sysent.c sysv_msg.c sysv_sem.c Message-ID: <200108310230.f7V2Uis61771@earth.backplane.com> References: <Pine.BSF.4.30.0108302159470.19462-100000@niwun.pair.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:There could be cases where you'd want to drop Giant earlier than at the
:end of the function too, I suppose. (Possibly in cases where you only
:need Giant to grab certain pieces of data, then can go on with a more
:local mutex.)
:
:Actually, I guess now would be a good time to ask. Is grabbing Giant late
:/ dropping it early a problem? I ask because I'm unclear if it's bad to
:have a function that's only part Giant-dependant.
:
:Obviously you could introduce races / other nasty conditions by not
:encapsulating the whole function in Giant - the question above is stated
:assuming that you have not introduced any races / bugs. :)
:
:Mike "Silby" Silbersack
As long as you aren't holding any other mutexes when you aquire Giant
and the stuff outside of Giant is MP-SAFE, and there are no atomicy
constraints between the Giant-locked sections making up the syscall,
and you are holding a reference on structural objects you hold through a
loss of Giant (and you are holding references on objects held if you
block while holding Giant)... then you can obtain and drop Giant
all you want.
A good example of this is the vm/vm_mmap.c:mmap(). It does most of
its (mp-safe) argument checking prior to obtaining Giant. Ignore
the tail end where it releases Giant early -- that's actually a bug
because it hasn't REF'd the vnode (which I'm about to fix). But the
first part is ok.
Two areas where we don't do a good job holding references are VM objects
and file pointers. We do a fairly good job holding references on vnodes
now but (as one can see with mmap()) there are still a few places that
we've missed. With proper structural reference counts maintained there
are fewer issues involved with holding Giant in a piecemeal fashion.
The biggest issue involved with doing Giant unwinding work is that it
is a moving target. For example, holding Giant currently keeps you safe
in regards to accessing things like p_ucred, but as JHB installs the
PROC lock and then we remove the Giant requirement from things like,
oh, setuid(), suddenly it is no longer safe to only be holding Giant
if you need to access p_ucred.
-Matt
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200108310230.f7V2Uis61771>