From owner-cvs-all Thu Aug 30 19:59:20 2001 Delivered-To: cvs-all@freebsd.org Received: from earth.backplane.com (earth.backplane.com [208.161.114.65]) by hub.freebsd.org (Postfix) with ESMTP id 2359337B405; Thu, 30 Aug 2001 19:59:11 -0700 (PDT) (envelope-from dillon@earth.backplane.com) Received: (from dillon@localhost) by earth.backplane.com (8.11.6/8.11.2) id f7V2Uis61771; Thu, 30 Aug 2001 19:30:44 -0700 (PDT) (envelope-from dillon) Date: Thu, 30 Aug 2001 19:30:44 -0700 (PDT) From: Matt Dillon Message-Id: <200108310230.f7V2Uis61771@earth.backplane.com> To: Mike Silbersack Cc: John Baldwin , , Subject: Re: RE: cvs commit: src/sys/kern init_sysent.c sysv_msg.c sysv_sem.c References: Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG :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