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