Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1596697 > unrolled thread

[PATCH net] rxrpc: Wake up the transmitter if Rx window size increases on the peer

Started byDavid Howells <dhowells@redhat.com>
First post2017-03-10 08:50 +0100
Last post2017-03-10 18:40 +0100
Articles 2 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH net] rxrpc: Wake up the transmitter if Rx window size  increases on the peer David Howells <dhowells@redhat.com> - 2017-03-10 08:50 +0100
    Re: [PATCH net] rxrpc: Wake up the transmitter if Rx window size  increases on the peer David Miller <davem@davemloft.net> - 2017-03-10 18:40 +0100

#1596697 — [PATCH net] rxrpc: Wake up the transmitter if Rx window size increases on the peer

FromDavid Howells <dhowells@redhat.com>
Date2017-03-10 08:50 +0100
Subject[PATCH net] rxrpc: Wake up the transmitter if Rx window size increases on the peer
Message-ID<tjntg-v0-1@gated-at.bofh.it>
The RxRPC ACK packet may contain an extension that includes the peer's
current Rx window size for this call.  We adjust the local Tx window size
to match.  However, the transmitter can stall if the receive window is
reduced to 0 by the peer and then reopened.

This is because the normal way that the transmitter is re-energised is by
dropping something out of our Tx queue and thus making space.  When a
single gap is made, the transmitter is woken up.  However, because there's
nothing in the Tx queue at this point, this doesn't happen.

To fix this, perform a wake_up() any time we see the peer's Rx window size
increasing.

The observable symptom is that calls start failing on ETIMEDOUT and the
following:

	kAFS: SERVER DEAD state=-62

appears in dmesg.

Signed-off-by: David Howells <dhowells@redhat.com>
---

 net/rxrpc/input.c |   15 ++++++++++++---
 1 file changed, 12 insertions(+), 3 deletions(-)

diff --git a/net/rxrpc/input.c b/net/rxrpc/input.c
index d74921c4969b..18b2ad8be8e2 100644
--- a/net/rxrpc/input.c
+++ b/net/rxrpc/input.c
@@ -652,6 +652,7 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, struct sk_buff *skb,
 	struct rxrpc_skb_priv *sp = rxrpc_skb(skb);
 	struct rxrpc_peer *peer;
 	unsigned int mtu;
+	bool wake = false;
 	u32 rwind = ntohl(ackinfo->rwind);
 
 	_proto("Rx ACK %%%u Info { rx=%u max=%u rwin=%u jm=%u }",
@@ -659,9 +660,14 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, struct sk_buff *skb,
 	       ntohl(ackinfo->rxMTU), ntohl(ackinfo->maxMTU),
 	       rwind, ntohl(ackinfo->jumbo_max));
 
-	if (rwind > RXRPC_RXTX_BUFF_SIZE - 1)
-		rwind = RXRPC_RXTX_BUFF_SIZE - 1;
-	call->tx_winsize = rwind;
+	if (call->tx_winsize != rwind) {
+		if (rwind > RXRPC_RXTX_BUFF_SIZE - 1)
+			rwind = RXRPC_RXTX_BUFF_SIZE - 1;
+		if (rwind > call->tx_winsize)
+			wake = true;
+		call->tx_winsize = rwind;
+	}
+
 	if (call->cong_ssthresh > rwind)
 		call->cong_ssthresh = rwind;
 
@@ -675,6 +681,9 @@ static void rxrpc_input_ackinfo(struct rxrpc_call *call, struct sk_buff *skb,
 		spin_unlock_bh(&peer->lock);
 		_net("Net MTU %u (maxdata %u)", peer->mtu, peer->maxdata);
 	}
+
+	if (wake)
+		wake_up(&call->waitq);
 }
 
 /*

[toc] | [next] | [standalone]


#1597974

FromDavid Miller <davem@davemloft.net>
Date2017-03-10 18:40 +0100
Message-ID<tjwGd-7eN-13@gated-at.bofh.it>
In reply to#1596697
From: David Howells <dhowells@redhat.com>
Date: Fri, 10 Mar 2017 07:48:49 +0000

> The RxRPC ACK packet may contain an extension that includes the peer's
> current Rx window size for this call.  We adjust the local Tx window size
> to match.  However, the transmitter can stall if the receive window is
> reduced to 0 by the peer and then reopened.
> 
> This is because the normal way that the transmitter is re-energised is by
> dropping something out of our Tx queue and thus making space.  When a
> single gap is made, the transmitter is woken up.  However, because there's
> nothing in the Tx queue at this point, this doesn't happen.
> 
> To fix this, perform a wake_up() any time we see the peer's Rx window size
> increasing.
> 
> The observable symptom is that calls start failing on ETIMEDOUT and the
> following:
> 
> 	kAFS: SERVER DEAD state=-62
> 
> appears in dmesg.
> 
> Signed-off-by: David Howells <dhowells@redhat.com>

Applied, thanks David.

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web