From owner-cvs-all Fri Aug 31 11:38: 3 2001 Delivered-To: cvs-all@freebsd.org Received: from technokratis.com (modemcable093.62-201-24.mtl.mc.videotron.ca [24.201.62.93]) by hub.freebsd.org (Postfix) with ESMTP id 9707337B403; Fri, 31 Aug 2001 11:37:48 -0700 (PDT) Received: (from bmilekic@localhost) by technokratis.com (8.11.4/8.11.3) id f7VIfA029245; Fri, 31 Aug 2001 14:41:10 -0400 (EDT) (envelope-from bmilekic) Date: Fri, 31 Aug 2001 14:41:10 -0400 From: Bosko Milekic To: Matt Dillon Cc: Mike Silbersack , John Baldwin , 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: <20010831144110.A29184@technokratis.com> References: <200108311755.f7VHtQl66146@earth.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <200108311755.f7VHtQl66146@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Aug 31, 2001 at 10:55:26AM -0700 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 On Fri, Aug 31, 2001 at 10:55:26AM -0700, Matt Dillon wrote: > Giant must be already held when calling any function not marked > MPSAFE. Functions marked MPSAFE may be called without Giant held > and thus must obtain Giant themselves if they call into functions > not marked MPSAFE. I wish it were that simple. But it isn't. It is not safe to drop Giant in a function merely because it (the function itself) is marked "MPSAFE." Let's say I have a function that is completely "MPSAFE," but this function is called inside a loop in some other function which is not "MPSAFE." Then, the data structures being manipulated in the non-MPSAFE function are only protected by Giant. So what happens if you unwind Giant before calling the completely "MPSAFE" routines, is that the data structures which may be manipulated in the loop of the non-MPSAFE routine may end up getting manipulated by another thread which may be able to acquire Giant at this point to manipulate them because our thread has dropped it before the call to the MPSAFE function. A real world example of this type of problem is, as I mentionned in another post, in the socket buffer code. Presently, the mbuf allocation functions are all MPSAFE. However, the socket buffer code is NOT MPSAFE at all, and you have a situation in sbdrop() where the socket buffer is being manipulated and mbufs from the socket buffer are being freed one after the other and so if you drop Giant in the mbuf allocation code, you risk having the socket buffer you're working on in sbdrop() get all messed up. One way to fix this is to re-write sbdrop() and all routines like it to first detach ALL the mbufs it needs from the socket buffer (while it still has Giant) and then free them in one shot. However, who knows how many places there are like this that would require this sort of re-write. Another way to solve this is to just wrap the loop in sbdrop() that manipulates the socket buffer with a lock on the socket buffer (this is how BSD/OS does it). It's a much easier solution, except that if we ever have routines that loop and ADD to a socket buffer (and thus require mbuf ALLOCATION), then we may need to perform the allocations with M_DONTWAIT, as this would ensure that we do not block on a condition variable in the mbuf allocator while holding the socket buffer lock. No big deal. > The time functions are only half-MPSAFE. They aren't 100% MPSAFE > but they are close. That's something I intend to review. > > -Matt -- Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message