release_sock causes recursion in tcp_v4_do_rcv?

Vijay G. Bharadwaj (vgb@isr.umd.edu)
Mon, 27 Apr 1998 19:42:34 -0400 (EDT)


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