[lkml]   [2000]   [Oct]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: tcp.c::wait_for_tcp_memory() buggy ?

On Sun, 29 Oct 2000, Rik van Riel wrote:

> I can't quite put my finger on what wait_for_tcp_memory() is supposed
> to do, [...]

it's waiting for TCP output packets to be processed. This is a TCP
protocol detail and is not connected to VM issues. The function name might
be a bit misleading, it could be 'tcp_write_possible()', or

> [...] but the code looks EXTREMELY suspect and I've had a report of
> somebody looping in the for(;;) loop in that function without ever
> exiting and getting his TCP connection stuck there...

as far as i understand, this can happen if another host (for whatever
reason) does not process the TCP output packets this host has sent.

> Also, the locking inside the loop seems fragile, to say the
> least.
> from tcp.c:
> 865 if (tcp_memory_free(sk) && !vm_wait)
> 866 break;
> 880 release_sock(sk);
> 881 if (!tcp_memory_free(sk) || vm_wait)
> 882 current_timeo = schedule_timeout(current_timeo);
> 883 lock_sock(sk);
> Here we hold the lock for the entire loop (meaning that
> other people cannot make the exit condition on line 865
> come true.

we do not keep the lock for the entire loop, we schedule away on line 882
with the socket lock dropped. This is a pretty standard (and safe) locking

> Except for doing a test on tcp_memory_free(sk), where we
> do NOT hold the lock we're so dutifully clinging to during
> the rest of the loop...

well, thats the point of the socket lock - we can access socket data
structures almost only via the socket lock.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

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