mptcp:sched: penalise all slow subflows

Not only the first one we found: the one that has already sent the SKB
and is slower than the selected one.

Because for the same connection, we will always iterate subflows in the
same order, we might always penalise the same subflow. The impact of
this patch will only be visible when there are more than 2 subflows and
we are limited by received windows.

Note that it might be interesting to penalise only the worst subflow or
balance the penalisation but we should not often have a situation where
we have a lot of reinjections of the same segment over multiple paths.
So this fix looks like a good first step to improve use cases where more
than two subflows are used.

Fixes: 17a4d79 (Receive-buffer)
Signed-off-by: Matthieu Baerts <matthieu.baerts@tessares.net>
Signed-off-by: Tim Froidcoeur <tim.froidcoeur@tessares.net>
Signed-off-by: Christoph Paasch <cpaasch@apple.com>
(cherry picked from commit b98b373)
Signed-off-by: Christoph Paasch <cpaasch@apple.com>

net/mptcp/mptcp_sched.c

@@ -291,7 +291,7 @@ static struct sk_buff *mptcp_rcv_buf_optimization(struct sock *sk, int penal)
 	if (tcp_jiffies32 - def_p->last_rbuf_opti < usecs_to_jiffies(tp->srtt_us >> 3))
 		goto retrans;
 
-	/* Half the cwnd of the slow flow */
+	/* Half the cwnd of the slow flows */
 	mptcp_for_each_sub(tp->mpcb, mptcp) {
 		struct tcp_sock *tp_it = mptcp->tp;
 
@@ -308,7 +308,6 @@ static struct sk_buff *mptcp_rcv_buf_optimization(struct sock *sk, int penal)
 
 				def_p->last_rbuf_opti = tcp_jiffies32;
 			}
-			break;
 		}
 	}