The MSS idea would not have worked anyways. The broken programs usually do:
sk = accept(...);
silly_value = 512;
setsockopt(sk, SO_RCVBUF, &silly_value, ...);
And after the accept the 3way handshake is already finished and you can't change
the MSS anymore.
>
> I also fixed the TCP to always send back an ack to the other end (since I
> understood by Alan's email of yesterday, that this thing has to happen) if
> we are forced to drop the incoming packet because we have just a lot of
> data queued.
If the data is dropped it cannot be acked. Acking earlier data does not make
any sense, because the other end cannot do anything more than to retransmit,
and it should do that anyways even when we send no ack. What Alan said is that
Linux must process all ack or window update information in the dropped packet,
and this is guaranteed anyways because tcp_ack is unconditionally called before
tcp_data. Sending an ack is only required when out of order data arrives (but strictly
only when it is accepted,which it isn't in this case). It may still be nice.
Also disabling header prediction is not required (the user may eat the buffer backlog
and everything could be fine again when the next retransmit arrives)
Now I must say your latest iteration of the deadlock fix looks ok for me, although
I think you should move the logic to a common function that is called by both prune_queue
and the setsockopt code.
-Andi
-
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/