> 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