>This looks wrong. In nonblocking case the "break" exits the loop and
>cleanup_rbuf() will be called then anyway. You probably overlooked that
>there are 2 cleanup_rbuf() calls, one in the loop and one at the end
>of the function.
Yes I overlooked. Excuse me.
>> + * will avoid us to deadlock here. -arca
>> + */
>> + schedule_timeout(10*HZ);
>
>What is this timeout supposed to do exactly?
It will unblock after 10 sec if not wakenup before by the reception of
some new packet.
So after 10 sec the loop restart and you'll be inside cleanup_rbuf again
and you'll send a new ack. Dave said it's not needed though so probably I
missed something here too.
>Im missing a timeout at the senders side acording to RFC1122/4.2.3.4:
>
>"To avoid a resulting
>deadlock, it is necessary to have a timeout to force
>transmission of data, overriding the SWS avoidance
>algorithm. In practice, this timeout should seldom
>occur."
This was in the case that rcvbuf got shrunk if I remember well. But I
can't continue to play with linux now so I'll have a look at these issues
again this night.
Andrea Arcangeli
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/