Date: Fri, 31 Aug 2001 14:41:10 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: Matt Dillon <dillon@earth.backplane.com> Cc: Mike Silbersack <silby@silby.com>, 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: <20010831144110.A29184@technokratis.com> In-Reply-To: <200108311755.f7VHtQl66146@earth.backplane.com>; from dillon@earth.backplane.com on Fri, Aug 31, 2001 at 10:55:26AM -0700 References: <Pine.BSF.4.30.0108302309010.75391-100000@niwun.pair.com> <200108311755.f7VHtQl66146@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010831144110.A29184>