Date: Wed, 10 Jan 2007 14:31:57 -0500 From: John Baldwin <jhb@freebsd.org> To: Randall Stewart <rrs@cisco.com> Cc: Craig Rodrigues <rodrigc@crodrigues.org>, freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: Witness warning with SCTP Message-ID: <200701101431.57695.jhb@freebsd.org> In-Reply-To: <45A5004B.6090402@cisco.com> References: <20070107171034.GA13836@crodrigues.org> <20070110142100.G52843@fledge.watson.org> <45A5004B.6090402@cisco.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wednesday 10 January 2007 10:03, Randall Stewart wrote:
> Robert/All:
>
> Ok, here is the deal... I have looked in a bit
> closer at this..
>
> Here is what is happening...
>
> When a cookie arrives, we get a "create lock" on
> the socket this prevents the user on the same
> socket from creating a assoc at the same exact time.
Can't you do a model like this:
lock();
if (need to create pcb) {
unlock();
create_pcb(); // can sleep w/o holding lock
lock();
if (someone else created the pcb)
free(pcb_I_just_created);
}
unlock();
This is used in several places in the kernel to handle concurrent
object creation races. Speaking of the sx(9) man page there are
two things to note:
1) There are already patches to make sx(9) locks just as efficient
as mutexes in the common case (single atomic op), so that comment
is likely irrelevant (and probably shouldn't have existed in the
first place).
2) If you are already willing to sleep by calling hashinit() (which
can sleep in malloc()), then blocking on a sx lock is already fine
for the code where you are doing this.
--
John Baldwin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200701101431.57695.jhb>