[AF_RXRPC]: Sort out MTU handling.

Sort out the MTU determination and handling in AF_RXRPC:

 (1) If it's present, parse the additional information supplied by the peer at
     the end of the ACK packet (struct ackinfo) to determine the MTU sizes
     that peer is willing to support.

 (2) Initialise the MTU size to that peer from the kernel's routing records.

 (3) Send ACKs rather than ACKALLs as the former carry the additional info,
     and the latter do not.

 (4) Declare the interface MTU size in outgoing ACKs as a maximum amount of
     data that can be stuffed into an RxRPC packet without it having to be
     fragmented to come in this computer's NIC.

 (5) If sendmsg() is given MSG_MORE then it should allocate an skb of the
     maximum size rather than one just big enough for the data it's got left
     to process on the theory that there is more data to come that it can
     append to that packet.

     This means, for example, that if AFS does a large StoreData op, all the
     packets barring the last will be filled to the maximum unfragmented size.

Signed-off-by: David Howells <dhowells@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>

1 files changed, 2 insertions, 0 deletions

diff --git a/net/rxrpc/ar-error.c b/net/rxrpc/ar-error.c
index 2c27df1..6cb3e88 100644
--- a/net/rxrpc/ar-error.c
+++ b/net/rxrpc/ar-error.c
@@ -100,8 +100,10 @@ void rxrpc_UDP_error_report(struct sock *sk)
 		}
 
 		if (mtu < peer->mtu) {
+			spin_lock_bh(&peer->lock);
 			peer->mtu = mtu;
 			peer->maxdata = peer->mtu - peer->hdrsize;
+			spin_unlock_bh(&peer->lock);
 			_net("Net MTU %u (maxdata %u)",
 			     peer->mtu, peer->maxdata);
 		}