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 'tcp_wmem_free()'. > [...] 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 technique. > 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. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/