afs: Adjust ACK interpretation to try and cope with NAT

If a client's address changes, say if it is NAT'd, this can disrupt an in
progress operation.  For most operations, this is not much of a problem,
but StoreData can be different as some servers modify the target file as
the data comes in, so if a store request is disrupted, the file can get
corrupted on the server.

The problem is that the server doesn't recognise packets that come after
the change of address as belonging to the original client and will bounce
them, either by sending an OUT_OF_SEQUENCE ACK to the apparent new call if
the packet number falls within the initial sequence number window of a call
or by sending an EXCEEDS_WINDOW ACK if it falls outside and then aborting
it.  In both cases, firstPacket will be 1 and previousPacket will be 0 in
the ACK information.

Fix this by the following means:

 (1) If a client call receives an EXCEEDS_WINDOW ACK with firstPacket as 1
     and previousPacket as 0, assume this indicates that the server saw the
     incoming packets from a different peer and thus as a different call.
     Fail the call with error -ENETRESET.

 (2) Also fail the call if a similar OUT_OF_SEQUENCE ACK occurs if the
     first packet has been hard-ACK'd.  If it hasn't been hard-ACK'd, the
     ACK packet will cause it to get retransmitted, so the call will just
     be repeated.

 (3) Make afs_select_fileserver() treat -ENETRESET as a straight fail of
     the operation.

 (4) Prioritise the error code over things like -ECONNRESET as the server
     did actually respond.

 (5) Make writeback treat -ENETRESET as a retryable error and make it
     redirty all the pages involved in a write so that the VM will retry.

Note that there is still a circumstance that I can't easily deal with: if
the operation is fully received and processed by the server, but the reply
is lost due to address change.  There's no way to know if the op happened.
We can examine the server, but a conflicting change could have been made by
a third party - and we can't tell the difference.  In such a case, a
message like:

    kAFS: vnode modified {100058:146266} b7->b8 YFS.StoreData64 (op=2646a)

will be logged to dmesg on the next op to touch the file and the client
will reset the inode state, including invalidating clean parts of the
pagecache.

Reported-by: Marc Dionne <marc.dionne@auristor.com>
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-afs@lists.infradead.org
Link: http://lists.infradead.org/pipermail/linux-afs/2021-December/004811.html
Signed-off-by: David S. Miller <davem@davemloft.net>

diff --git a/fs/afs/misc.c b/fs/afs/misc.c
index 1d1a8debe4723e4b0d5a69e892cd4389f07ef1c8..933e67fcdab1a722c4954e18bed11dd08fc6b8e1 100644 (file)
--- a/fs/afs/misc.c
+++ b/fs/afs/misc.c
@@ -163,8 +163,11 @@ void afs_prioritise_error(struct afs_error *e, int error, u32 abort_code)
                return;
 
        case -ECONNABORTED:
+               error = afs_abort_to_error(abort_code);
+               fallthrough;
+       case -ENETRESET: /* Responded, but we seem to have changed address */
                e->responded = true;
-               e->error = afs_abort_to_error(abort_code);
+               e->error = error;
                return;
        }
 }

diff --git a/fs/afs/rotate.c b/fs/afs/rotate.c
index 79e1a5f6701bed9822bb17e324740b6da13b94da..a840c3588ebbbc41bf9a65fe74207003ea244ea5 100644 (file)
--- a/fs/afs/rotate.c
+++ b/fs/afs/rotate.c
@@ -292,6 +292,10 @@ bool afs_select_fileserver(struct afs_operation *op)
                op->error = error;
                goto iterate_address;
 
+       case -ENETRESET:
+               pr_warn("kAFS: Peer reset %s (op=%x)\n",
+                       op->type ? op->type->name : "???", op->debug_id);
+               fallthrough;
        case -ECONNRESET:
                _debug("call reset");
                op->error = error;

diff --git a/fs/afs/write.c b/fs/afs/write.c
index 4763132ca57e7f53d4ca82ab64282fe8a3848f11..c1bc52ac7de1119ebaa395c22e2952acc1dc63e2 100644 (file)
--- a/fs/afs/write.c
+++ b/fs/afs/write.c
@@ -636,6 +636,7 @@ static ssize_t afs_write_back_from_locked_folio(struct address_space *mapping,
        case -EKEYEXPIRED:
        case -EKEYREJECTED:
        case -EKEYREVOKED:
+       case -ENETRESET:
                afs_redirty_pages(wbc, mapping, start, len);
                mapping_set_error(mapping, ret);
                break;

diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index 853b869b026a7786c7e0436dca35cb723ba6e2be..16c0af41c202ae2c7b6c53299b712ceb2585788a 100644 (file)
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -903,6 +903,33 @@ static void rxrpc_input_ack(struct rxrpc_call *call, struct sk_buff *skb)
                                  rxrpc_propose_ack_respond_to_ack);
        }
 
+       /* If we get an EXCEEDS_WINDOW ACK from the server, it probably
+        * indicates that the client address changed due to NAT.  The server
+        * lost the call because it switched to a different peer.
+        */
+       if (unlikely(buf.ack.reason == RXRPC_ACK_EXCEEDS_WINDOW) &&
+           first_soft_ack == 1 &&
+           prev_pkt == 0 &&
+           rxrpc_is_client_call(call)) {
+               rxrpc_set_call_completion(call, RXRPC_CALL_REMOTELY_ABORTED,
+                                         0, -ENETRESET);
+               return;
+       }
+
+       /* If we get an OUT_OF_SEQUENCE ACK from the server, that can also
+        * indicate a change of address.  However, we can retransmit the call
+        * if we still have it buffered to the beginning.
+        */
+       if (unlikely(buf.ack.reason == RXRPC_ACK_OUT_OF_SEQUENCE) &&
+           first_soft_ack == 1 &&
+           prev_pkt == 0 &&
+           call->tx_hard_ack == 0 &&
+           rxrpc_is_client_call(call)) {
+               rxrpc_set_call_completion(call, RXRPC_CALL_REMOTELY_ABORTED,
+                                         0, -ENETRESET);
+               return;
+       }
+
        /* Discard any out-of-order or duplicate ACKs (outside lock). */
        if (!rxrpc_is_ack_valid(call, first_soft_ack, prev_pkt)) {
                trace_rxrpc_rx_discard_ack(call->debug_id, ack_serial,