Witness warning with SCTP
John Baldwin
jhb at freebsd.org
Wed Jan 10 14:25:31 PST 2007
On Wednesday 10 January 2007 15:03, Randall Stewart wrote:
> 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 :-()
Ah, you must have missed the part where it does:
if (someone else created the pcb) {
free(pcb I just created);
use the other pcb;
}
:-P That is, explicitly handling the race. However:
> 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.
In that case a hashinit_flags() is the way to go I guess. What happens if
the hashinit fails, connection dropped?
--
John Baldwin
More information about the freebsd-current
mailing list