Skip to contentSkip to conversation

Linux 2.2.16 through 2.2.18preX TCP hang bug triggered by rsync

DISCUSSION Studierende der Universitaet des Saarlandes 2 participants 2 messages Jan 25, 2001

lore
Share & tools
lore
#0 lore raw
Quoted 4 lines · Andi

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.

But it seems that that's exactly what rsync does:
It performs bulk data writes without reading. There are 32 kB in the receive buffers, and rsync continues to write. If the process would read some data the TCP stack would immediately recover.

RST are already processed, ACK's should be processed, but what about URG?

--
Manfred
-
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/

#1 lore raw
Quoted 10 lines · Studierende der Universitaet des Saarlandes
Quoted 4 lines · Andi

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.

But it seems that that's exactly what rsync does:
It performs bulk data writes without reading. There are 32 kB in the receive buffers, and rsync continues to write. If the process would read some data the TCP stack would immediately recover.

Yes, but it has 64K of buffer. The other 32K are for skb headers. When it is sending MTU sized packets (and the MTU has any reasonable value) then most of the other 32K are empty (a skb has ~150 bytes overhead) and you could fit a few such bogus acks with data into that.

Quoted 2 lines

RST are already processed, ACK's should be processed, but what about URG?

Nobody cares about URG, it is broken anyways ;)

-Andi
-
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/