rxrpc: Fix detection of out of order acks
authorJeffrey Altman <jaltman@auristor.com>
Fri, 12 Apr 2019 15:34:16 +0000 (16:34 +0100)
committerDavid S. Miller <davem@davemloft.net>
Fri, 12 Apr 2019 23:57:23 +0000 (16:57 -0700)
commit1a2391c30c0b9d041bc340f68df81d49c53546cc
treeadec0da77205b01e590914e28aca0930926f9949
parent39ce67557568962fa9d1593741f76c4cc6762469
rxrpc: Fix detection of out of order acks

The rxrpc packet serial number cannot be safely used to compute out of
order ack packets for several reasons:

 1. The allocation of serial numbers cannot be assumed to imply the order
    by which acks are populated and transmitted.  In some rxrpc
    implementations, delayed acks and ping acks are transmitted
    asynchronously to the receipt of data packets and so may be transmitted
    out of order.  As a result, they can race with idle acks.

 2. Serial numbers are allocated by the rxrpc connection and not the call
    and as such may wrap independently if multiple channels are in use.

In any case, what matters is whether the ack packet provides new
information relating to the bounds of the window (the firstPacket and
previousPacket in the ACK data).

Fix this by discarding packets that appear to wind back the window bounds
rather than on serial number procession.

Fixes: 298bc15b2079 ("rxrpc: Only take the rwind and mtu values from latest ACK")
Signed-off-by: Jeffrey Altman <jaltman@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
Tested-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
net/rxrpc/ar-internal.h
net/rxrpc/input.c