lkml.org 
[lkml]   [1998]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
Subjectrelease_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

\
 
 \ /
  Last update: 2005-03-22 13:42    [W:0.030 / U:1.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site