Re: Witness warning with SCTP

From: John Baldwin <jhb_at_freebsd.org>
Date: Wed, 10 Jan 2007 15:15:29 -0500
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
Received on Wed Jan 10 2007 - 21:25:30 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:04 UTC