Messages in this thread | | | Date | Mon, 27 Apr 1998 19:42:34 -0400 (EDT) | From | "Vijay G. Bharadwaj" <> | Subject | release_sock causes recursion in tcp_v4_do_rcv? |
| |
I was just looking at the TCP layer in 2.1.9x and I have a question - the current implementation of release_sock() calls sk->backlog_rcv() after unlocking the socket by decrementing sk->sock_readers. Now one of the places this happens is in tcp_v4_do_rcv(), which is also sk->backlog_rcv() for TCPv4 sockets. So if more than one packets are queued to a TCP socket at a time, then here's what happens:
tcp_v4_do_rcv() is called
It locks the socket - sk->sock_readers=1 (assume it wasn't locked before)
Packet is received, whatever...
tcp_v4_do_rcv calls release_sock(), which sets sk->sock_readers to 0 and goes to __release_sock(), which calls sk->backlog_rcv(), ie tcp_v4_do_rcv(), all over again.
OK so this doesn't break anything, but I still think it's ugly. tcp_v4_do_rcv() is effectively doing a recursion, and at least in this case it seems unnecessary. IMHO the call to sk->backlog_rcv should be taken out of __release_sock(), and instead, tcp_v4_do_rcv() should do a while() on the receive queue, receiving as many packets as are queued, or as many as it feels like doing (ie maybe an upper limit, like the 300 limit in net_bh()). The present way is I think slower and a waste of stack space.
But I've been wrong before. Could somebody please comment? Am I missing something? Admittedly I know nothing at all about SMP...
-Vijay
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu
| |