rx-dont-ackall-a-connection-were-waiting-for-retransmits-on-20011110
authorNickolai Zeldovich <kolya@mit.edu>
Sat, 10 Nov 2001 18:14:30 +0000 (18:14 +0000)
committerDerrick Brashear <shadow@dementia.org>
Sat, 10 Nov 2001 18:14:30 +0000 (18:14 +0000)
commitdb2ddfaf1b322710e1bd4edce6d7519157c3c9eb
tree51ed21478a8713fcd4ef7ed422bfc10e32a6b045
parent7a012ce879fdb6193b77e71821b1f9cce89c0fd6
rx-dont-ackall-a-connection-were-waiting-for-retransmits-on-20011110

"My theory of what happened is roughly as follows:

    Process tries to read data from AFS (as part of a page fault);
    issues a new Rx call on an Rx connection to the fileserver.

    The server transmits some data back to the client, but some packet
    is lost.

    Something tries to garbage-collect/destroy the connection; since
    there is an active call, it can't do so, but issues an rx_AckAll
    anyway, which acknowledges all packets transmitted by the server
    as having been received.  Server flushes its retransmit queue.

    Client waits forever for the lost packet to arrive, but since the
    server has already flushed the transmit queue, it cannot possibly
    retransmit it.

All this is happening while the client has read-locked its address
space (since the read is part of a page fault).  /proc accesses that
try to poke into that processes address space hang waiting for said
lock, causing the lossage we actually observed."
src/rx/rx.c