]> git.michaelhowe.org Git - packages/o/openafs.git/commit
STABLE12-rx-dont-ackall-a-connection-were-waiting-for-retransmits-on-20011229
authorNickolai Zeldovich <kolya@mit.edu>
Sat, 29 Dec 2001 23:18:46 +0000 (23:18 +0000)
committerDerrick Brashear <shadow@dementia.org>
Sat, 29 Dec 2001 23:18:46 +0000 (23:18 +0000)
commit84ea8c790e93de7a223eaf7f5334e2ddcb4e8428
tree1b6a6e41d38d0906a15d32c2cf7953d6014d338a
parent5e79c1ce4feb25a560b0c1f74b6a790e43062c87
STABLE12-rx-dont-ackall-a-connection-were-waiting-for-retransmits-on-20011229

"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