Date: Wed, 10 Jan 2007 15:03:14 -0500 From: Randall Stewart <rrs@cisco.com> To: John Baldwin <jhb@freebsd.org> Cc: Craig Rodrigues <rodrigc@crodrigues.org>, freebsd-current@freebsd.org, Robert Watson <rwatson@freebsd.org> Subject: Re: Witness warning with SCTP Message-ID: <45A54682.9040503@cisco.com> In-Reply-To: <200701101431.57695.jhb@freebsd.org> References: <20070107171034.GA13836@crodrigues.org> <20070110142100.G52843@fledge.watson.org> <45A5004B.6090402@cisco.com> <200701101431.57695.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
John:
John Baldwin wrote:
> 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();
The above is exactly what causes the race to occur..
There are several places where if we do that we end
up with two TCB's under certain collision cases.. which
can happen (I have a test app that gets it within a
few hours :-()
>
> 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).
ok
>
> 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.
>
I am NOT willing to sleep. the normal allocation of the PCB is done
with a WAIT type option.. I had not realized that hashinit()
did an allocation and could sleep.. thats the issue.
I think the easiest way is to just go ahead and either
have a specific hashinit() for sctp.. or redo hashinit
to have a hashinit_flags() as we have been discussing.. and
have the original hashinit() call that with WAIT.. and that
would then allow a WAIT or NOWAIT ...
R
--
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45A54682.9040503>