venugopal iyer wrote:
usr/src/uts/common/inet/sctp/sctp_impl.h
L900-903 (old code) : could removing this cause any
overflow/deadlock
issues etc. i.e in a loopback case could this thread send the packet
and when it gets to the receiving SCTP can it continue (assuming
sctp_recvq is null) and then get back with the response..
handshake?
could this exchange lead to stack overflow?
Existing code does not use the sendq to send INIT and INIT-ACK.
If there is a problem, we should have seen it.
Also, when we call
sctp_output from sctp_sendmsg we now has sctp_running set, when the
loopback thread (in the above scenario) comes back we'd probably
queue the packet in the receive queue and ask the task queue to
process it, but will then wait in sctp_process_recvq since
sctp_output
has still not returned to WAKE_SCTP, is that so?
In the above case, after queueing the packet, the thread will
return and eventually releases the lock on the sctp_t. Then
the taskq can work on the packet. It seems to be OK.
This is different from the current code. In the current code,
the lock on sctp_t is released before the packet is sent to
IP. So the thread will take the INIT to the loopback receiver,
do the processing and return with an INIT-ACK. The thread can
then grab the lock on the loopback sender sctp_t, process the
INIT-ACK and bring the resulting COOKIE-ECHO back to the
receiver. But it will stop here and return.
Did we check
loopback
tests? Sorry if I am missing something obvious.
I think we don't need to handle the loopback case in a special
way.
--
K. Poon.
[email protected]
_______________________________________________
networking-discuss mailing list
[email protected]
