Re: Witness warning with SCTP

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.

This is needed since the one-2-many model can
have connections establishing  both in an
active and passive mode at the same time.

Since this lock is in place, we now get the warning
where we never used to (I was finding a collision case
when with an app that was not protected and ending
up with two associations to the same place.. not good).

Now, the problem is in the 1-2-1 model. This is
a "tcp emulation' model and it does the sonewconn()
stuff.. which ends up creating a PCB and thus does
the hashinit(). The PCB is then put on the forming
connections queue of the socket... and later
an accept will pull it in.

Now thinking about this, I might be able to NOT
get the create lock on the socket if its a 1-2-1
model socket. This is because 1-2-1 models are
not allowed to both create active and passive
connections at the same time.

However, if I do that, there is another danger.
If I am a passive 1-2-1 socket, and the peer
gets two cookies to me at the same exact moment
(picture a network delay in one packet, a retrasmission
  of the other and they arrive at the same time). I
am going to hit this case again and possibly create
two associations at once. Thinking about this.. TCP
may well have the same issue... of course it uses
coarser grain locking so it might not see this.

I can change things so we have this one hole.. as a known
cavet.. its a disaster when you create two by the way...

But it would be a rare occurrence..

Either that or.. I am back to my same two options

hashinit_flags(...)
or
sctp_hashint(..) (which I have implemented for 6.0/6.1 and
                   of course MAC which don't have these.. of
                   course the main BSD tree never sees these
                   since unifdef removes them).

I can go with any of the above options.. however I would
strongly not recommend the first .. since I think any
rare thing.. will surely happen ;-0

R


Robert Watson wrote:
> 
> On Tue, 9 Jan 2007, John Baldwin wrote:
> 
>> Either that or use an sx lock to close the pcb alloc race instead and 
>> don't hold mutexes while calling hashinit().
> 
> I think this is a good point -- I've generally been restructuring PCB 
> init functions so that they perform allocation up front before acquiring 
> locks in order to reduce lock contention on the table locks, which are 
> global and acquired in many other paths.  This tends to simplify error 
> handling also. I'm not sure how well that applies in this case, 
> however.  Certainly, we want to optimize for successful handling, since 
> malloc(9) failure is very unusual and occurs only in very exceptional 
> (and unfortunate) cases.  A more likely failure is the exhaustion of the 
> zone limit on the pcb zone, which gates the overall allocation of memory 
> for the socket type, and should be the first memory type allocated when 
> setting up pcbs for this reason.
> 
> Robert N M Watson
> Computer Laboratory
> University of Cambridge
> _______________________________________________
> freebsd-current_at_freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe_at_freebsd.org"
> 


-- 
Randall Stewart
NSSTG - Cisco Systems Inc.
803-345-0369 <or> 803-317-4952 (cell)