Date: Fri, 31 Aug 2001 12:31:53 -0700 (PDT) From: Matt Dillon <dillon@earth.backplane.com> To: Bosko Milekic <bmilekic@technokratis.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: <200108311931.f7VJVr367085@earth.backplane.com> References: <Pine.BSF.4.30.0108302309010.75391-100000@niwun.pair.com> <200108311755.f7VHtQl66146@earth.backplane.com> <20010831144110.A29184@technokratis.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
Huh? Giant may or may not be held on entry to a function marked MPSAFE.
That doesn't mean the function marked MPSAFE is allowed to drop Giant!
No function should drop someone else's Giant except the scheduler
itself when a normal blocking condition occurs.
: 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.
:...
: Bosko Milekic
: bmilekic@technokratis.com
Again, nobody is suggestion that MPSAFE code should drop someone
else's Giant.
The whole point with Giant is that it is mostly 'invisible' to MPSAFE
code. That's why the scheduler treats it specially... saving and
restoring the Giant mutex. Only a blocking condition can drop Giant,
and that is a condition that our codebase already understands and deals
with. If someone is taking previously non-blocking MP unsafe procedures
and turning them into blocking procedures, we are in deep trouble.
-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?200108311931.f7VJVr367085>