> How do you define the order between teh two inp locks to ensure you don't > end up deadlocking?
One is the listening connection and the other is the newly created connection. The two inp locks are always acquired in the same order, so there's no possibility of deadlock here. Another case of holding 2 inp locks comes up when traversing the protocol pcb list and holding on to the last inp of interest while examining the rest of the inps to see if there's another one of interest. The pcb list is always walked in sequential list order with a lock held on the list, so there's no possibility of deadlock here. I don't want to add MTX_DUPOK to the inp lock yet, because I want to catch all the cases where duplicate inp locks are held and examine them by hand. But the ones I've investigated so far have been intentional. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
