Re: Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync

[Andi Kleen]

On Thu, Jan 25, 2001 at 03:44:07AM -0800, David S. Miller wrote:
> 
> Andi Kleen writes:
>  > > BSD and Solaris both make these kinds of packets, therefore it is must
>  > > to handle them properly.  So we will fix Linux, there is no argument.
>  > 
>  > How do you propose to handle them? Queue the data anyways or just process
>  > the ACK?
> 
> tcp_sequence returns two flag bits instead of it's current binary
> state.  One bit says "accept data", the other says "accept control
> bits" (such as RST, ACK, etc.)

Sounds ugly @) tcp_sequence is already far too complicated.

> 
> tcp_sequence also will truncate the data len of the SKB area if
> necessary, BSD really puts total crap in the probe byte.
> 
> Callers of tcp_sequence check the return value bits accordingly.
> This is all slow path code, so there are no performance issues.

How about simply queueing the data in that case if it already fits into the
receive buffer? The alternative would be to skb_trim() it to 0 in the slow path
of tcp_sequence and queue, but that looks wasteful.  Basically it would accept
the acks with the data in most cases except when the application has totally 
stopped reading and in that case it doesn't harm to ignore the acks. 

I have been played with a different embedded stack and it uses that 
approach and it seems to work and makes much simpler code. 

-Andi