2019-05-27 06:55:01 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0-or-later
|
2007-04-26 22:49:28 +00:00
|
|
|
/* miscellaneous bits
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
2007-04-26 22:55:03 +00:00
|
|
|
* Copyright (C) 2002, 2007 Red Hat, Inc. All Rights Reserved.
|
2005-04-16 22:20:36 +00:00
|
|
|
* Written by David Howells (dhowells@redhat.com)
|
|
|
|
|
*/
|
|
|
|
|
|
|
|
|
|
#include <linux/kernel.h>
|
|
|
|
|
#include <linux/module.h>
|
|
|
|
|
#include <linux/errno.h>
|
|
|
|
|
#include "internal.h"
|
2007-04-26 22:55:03 +00:00
|
|
|
#include "afs_fs.h"
|
2019-06-28 17:00:05 +00:00
|
|
|
#include "protocol_uae.h"
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* convert an AFS abort code to a Linux error number
|
|
|
|
|
*/
|
2007-04-26 22:55:03 +00:00
|
|
|
int afs_abort_to_error(u32 abort_code)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2007-04-26 22:55:03 +00:00
|
|
|
switch (abort_code) {
|
2017-11-02 15:27:48 +00:00
|
|
|
/* Low errno codes inserted into abort namespace */
|
2007-04-26 22:55:03 +00:00
|
|
|
case 13: return -EACCES;
|
2007-05-09 09:33:45 +00:00
|
|
|
case 27: return -EFBIG;
|
2007-04-26 22:59:35 +00:00
|
|
|
case 30: return -EROFS;
|
2014-08-21 18:10:55 +00:00
|
|
|
|
2017-11-02 15:27:48 +00:00
|
|
|
/* VICE "special error" codes; 101 - 111 */
|
2005-04-16 22:20:36 +00:00
|
|
|
case VSALVAGE: return -EIO;
|
|
|
|
|
case VNOVNODE: return -ENOENT;
|
2007-04-26 22:55:03 +00:00
|
|
|
case VNOVOL: return -ENOMEDIUM;
|
2005-04-16 22:20:36 +00:00
|
|
|
case VVOLEXISTS: return -EEXIST;
|
|
|
|
|
case VNOSERVICE: return -EIO;
|
|
|
|
|
case VOFFLINE: return -ENOENT;
|
|
|
|
|
case VONLINE: return -EEXIST;
|
|
|
|
|
case VDISKFULL: return -ENOSPC;
|
|
|
|
|
case VOVERQUOTA: return -EDQUOT;
|
|
|
|
|
case VBUSY: return -EBUSY;
|
|
|
|
|
case VMOVED: return -ENXIO;
|
2014-08-21 18:10:55 +00:00
|
|
|
|
2017-11-02 15:27:48 +00:00
|
|
|
/* Volume Location server errors */
|
|
|
|
|
case AFSVL_IDEXIST: return -EEXIST;
|
|
|
|
|
case AFSVL_IO: return -EREMOTEIO;
|
|
|
|
|
case AFSVL_NAMEEXIST: return -EEXIST;
|
|
|
|
|
case AFSVL_CREATEFAIL: return -EREMOTEIO;
|
|
|
|
|
case AFSVL_NOENT: return -ENOMEDIUM;
|
|
|
|
|
case AFSVL_EMPTY: return -ENOMEDIUM;
|
|
|
|
|
case AFSVL_ENTDELETED: return -ENOMEDIUM;
|
|
|
|
|
case AFSVL_BADNAME: return -EINVAL;
|
|
|
|
|
case AFSVL_BADINDEX: return -EINVAL;
|
|
|
|
|
case AFSVL_BADVOLTYPE: return -EINVAL;
|
|
|
|
|
case AFSVL_BADSERVER: return -EINVAL;
|
|
|
|
|
case AFSVL_BADPARTITION: return -EINVAL;
|
|
|
|
|
case AFSVL_REPSFULL: return -EFBIG;
|
|
|
|
|
case AFSVL_NOREPSERVER: return -ENOENT;
|
|
|
|
|
case AFSVL_DUPREPSERVER: return -EEXIST;
|
|
|
|
|
case AFSVL_RWNOTFOUND: return -ENOENT;
|
|
|
|
|
case AFSVL_BADREFCOUNT: return -EINVAL;
|
|
|
|
|
case AFSVL_SIZEEXCEEDED: return -EINVAL;
|
|
|
|
|
case AFSVL_BADENTRY: return -EINVAL;
|
|
|
|
|
case AFSVL_BADVOLIDBUMP: return -EINVAL;
|
|
|
|
|
case AFSVL_IDALREADYHASHED: return -EINVAL;
|
|
|
|
|
case AFSVL_ENTRYLOCKED: return -EBUSY;
|
|
|
|
|
case AFSVL_BADVOLOPER: return -EBADRQC;
|
|
|
|
|
case AFSVL_BADRELLOCKTYPE: return -EINVAL;
|
|
|
|
|
case AFSVL_RERELEASE: return -EREMOTEIO;
|
|
|
|
|
case AFSVL_BADSERVERFLAG: return -EINVAL;
|
|
|
|
|
case AFSVL_PERM: return -EACCES;
|
|
|
|
|
case AFSVL_NOMEM: return -EREMOTEIO;
|
|
|
|
|
|
2019-06-28 17:00:05 +00:00
|
|
|
/* Unified AFS error table */
|
|
|
|
|
case UAEPERM: return -EPERM;
|
|
|
|
|
case UAENOENT: return -ENOENT;
|
2022-09-06 21:09:11 +00:00
|
|
|
case UAEAGAIN: return -EAGAIN;
|
2019-06-28 17:00:05 +00:00
|
|
|
case UAEACCES: return -EACCES;
|
|
|
|
|
case UAEBUSY: return -EBUSY;
|
|
|
|
|
case UAEEXIST: return -EEXIST;
|
|
|
|
|
case UAENOTDIR: return -ENOTDIR;
|
|
|
|
|
case UAEISDIR: return -EISDIR;
|
|
|
|
|
case UAEFBIG: return -EFBIG;
|
|
|
|
|
case UAENOSPC: return -ENOSPC;
|
|
|
|
|
case UAEROFS: return -EROFS;
|
|
|
|
|
case UAEMLINK: return -EMLINK;
|
|
|
|
|
case UAEDEADLK: return -EDEADLK;
|
|
|
|
|
case UAENAMETOOLONG: return -ENAMETOOLONG;
|
|
|
|
|
case UAENOLCK: return -ENOLCK;
|
|
|
|
|
case UAENOTEMPTY: return -ENOTEMPTY;
|
|
|
|
|
case UAELOOP: return -ELOOP;
|
2020-06-14 21:12:05 +00:00
|
|
|
case UAEOVERFLOW: return -EOVERFLOW;
|
2019-06-28 17:00:05 +00:00
|
|
|
case UAENOMEDIUM: return -ENOMEDIUM;
|
|
|
|
|
case UAEDQUOT: return -EDQUOT;
|
2009-06-16 20:36:49 +00:00
|
|
|
|
2017-11-02 15:27:48 +00:00
|
|
|
/* RXKAD abort codes; from include/rxrpc/packet.h. ET "RXK" == 0x1260B00 */
|
2009-06-16 20:36:49 +00:00
|
|
|
case RXKADINCONSISTENCY: return -EPROTO;
|
|
|
|
|
case RXKADPACKETSHORT: return -EPROTO;
|
|
|
|
|
case RXKADLEVELFAIL: return -EKEYREJECTED;
|
|
|
|
|
case RXKADTICKETLEN: return -EKEYREJECTED;
|
|
|
|
|
case RXKADOUTOFSEQUENCE: return -EPROTO;
|
|
|
|
|
case RXKADNOAUTH: return -EKEYREJECTED;
|
|
|
|
|
case RXKADBADKEY: return -EKEYREJECTED;
|
|
|
|
|
case RXKADBADTICKET: return -EKEYREJECTED;
|
|
|
|
|
case RXKADUNKNOWNKEY: return -EKEYREJECTED;
|
|
|
|
|
case RXKADEXPIRED: return -EKEYEXPIRED;
|
|
|
|
|
case RXKADSEALEDINCON: return -EKEYREJECTED;
|
|
|
|
|
case RXKADDATALEN: return -EKEYREJECTED;
|
|
|
|
|
case RXKADILLEGALLEVEL: return -EKEYREJECTED;
|
|
|
|
|
|
2017-03-16 16:27:47 +00:00
|
|
|
case RXGEN_OPCODE: return -ENOTSUPP;
|
|
|
|
|
|
2007-04-26 22:59:35 +00:00
|
|
|
default: return -EREMOTEIO;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2007-04-26 22:49:28 +00:00
|
|
|
}
|
2018-11-13 23:20:28 +00:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Select the error to report from a set of errors.
|
|
|
|
|
*/
|
|
|
|
|
void afs_prioritise_error(struct afs_error *e, int error, u32 abort_code)
|
|
|
|
|
{
|
|
|
|
|
switch (error) {
|
|
|
|
|
case 0:
|
2023-10-25 16:53:33 +00:00
|
|
|
e->aborted = false;
|
|
|
|
|
e->error = 0;
|
2018-11-13 23:20:28 +00:00
|
|
|
return;
|
|
|
|
|
default:
|
|
|
|
|
if (e->error == -ETIMEDOUT ||
|
|
|
|
|
e->error == -ETIME)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -ETIMEDOUT:
|
|
|
|
|
case -ETIME:
|
|
|
|
|
if (e->error == -ENOMEM ||
|
|
|
|
|
e->error == -ENONET)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -ENOMEM:
|
|
|
|
|
case -ENONET:
|
|
|
|
|
if (e->error == -ERFKILL)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -ERFKILL:
|
|
|
|
|
if (e->error == -EADDRNOTAVAIL)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -EADDRNOTAVAIL:
|
|
|
|
|
if (e->error == -ENETUNREACH)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -ENETUNREACH:
|
|
|
|
|
if (e->error == -EHOSTUNREACH)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -EHOSTUNREACH:
|
|
|
|
|
if (e->error == -EHOSTDOWN)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -EHOSTDOWN:
|
|
|
|
|
if (e->error == -ECONNREFUSED)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -ECONNREFUSED:
|
|
|
|
|
if (e->error == -ECONNRESET)
|
|
|
|
|
return;
|
2020-08-23 22:36:59 +00:00
|
|
|
fallthrough;
|
2018-11-13 23:20:28 +00:00
|
|
|
case -ECONNRESET: /* Responded, but call expired. */
|
|
|
|
|
if (e->responded)
|
|
|
|
|
return;
|
|
|
|
|
e->error = error;
|
2023-10-25 16:53:33 +00:00
|
|
|
e->aborted = false;
|
2018-11-13 23:20:28 +00:00
|
|
|
return;
|
|
|
|
|
|
|
|
|
|
case -ECONNABORTED:
|
2023-10-25 16:53:33 +00:00
|
|
|
e->error = afs_abort_to_error(abort_code);
|
|
|
|
|
e->aborted = true;
|
|
|
|
|
e->responded = true;
|
|
|
|
|
return;
|
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 # v1
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 07:45:55 +00:00
|
|
|
case -ENETRESET: /* Responded, but we seem to have changed address */
|
2023-10-25 16:53:33 +00:00
|
|
|
e->aborted = false;
|
2018-11-13 23:20:28 +00:00
|
|
|
e->responded = true;
|
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 # v1
Signed-off-by: David S. Miller <davem@davemloft.net>
2022-05-21 07:45:55 +00:00
|
|
|
e->error = error;
|
2018-11-13 23:20:28 +00:00
|
|
|
return;
|
|
|
|
|
}
|
|
|
|
|
}
|
