All of lore.kernel.org
 help / color / mirror / Atom feed
* Patch "sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled" has been added to the 4.14-stable tree
@ 2018-01-13  9:52 gregkh
  0 siblings, 0 replies; only message in thread
From: gregkh @ 2018-01-13  9:52 UTC (permalink / raw)
  To: marcelo.leitner, davem, gregkh; +Cc: stable, stable-commits


This is a note to let you know that I've just added the patch titled

    sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled

to the 4.14-stable tree which can be found at:
    http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
     sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch
and it can be found in the queue-4.14 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.


>From foo@baz Sat Jan 13 10:51:05 CET 2018
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Date: Fri, 5 Jan 2018 11:17:17 -0200
Subject: sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled

From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>


[ Upstream commit cc35c3d1edf7a8373a1a5daa80a912dec96a9cd5 ]

Currently, if PMTU discovery is disabled on a given transport, but the
configured value is higher than the actual PMTU, it is likely that we
will get some icmp Frag Needed. The issue is, if PMTU discovery is
disabled, we won't update the information and will issue a
retransmission immediately, which may very well trigger another ICMP,
and another retransmission, leading to a loop.

The fix is to simply not trigger immediate retransmissions if PMTU
discovery is disabled on the given transport.

Changes from v2:
- updated stale comment, noticed by Xin Long

Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
 net/sctp/input.c |   24 ++++++++++++------------
 1 file changed, 12 insertions(+), 12 deletions(-)

--- a/net/sctp/input.c
+++ b/net/sctp/input.c
@@ -399,20 +399,20 @@ void sctp_icmp_frag_needed(struct sock *
 		return;
 	}
 
-	if (t->param_flags & SPP_PMTUD_ENABLE) {
-		/* Update transports view of the MTU */
-		sctp_transport_update_pmtu(t, pmtu);
+	if (!(t->param_flags & SPP_PMTUD_ENABLE))
+		/* We can't allow retransmitting in such case, as the
+		 * retransmission would be sized just as before, and thus we
+		 * would get another icmp, and retransmit again.
+		 */
+		return;
 
-		/* Update association pmtu. */
-		sctp_assoc_sync_pmtu(asoc);
-	}
+	/* Update transports view of the MTU */
+	sctp_transport_update_pmtu(t, pmtu);
+
+	/* Update association pmtu. */
+	sctp_assoc_sync_pmtu(asoc);
 
-	/* Retransmit with the new pmtu setting.
-	 * Normally, if PMTU discovery is disabled, an ICMP Fragmentation
-	 * Needed will never be sent, but if a message was sent before
-	 * PMTU discovery was disabled that was larger than the PMTU, it
-	 * would not be fragmented, so it must be re-transmitted fragmented.
-	 */
+	/* Retransmit with the new pmtu setting. */
 	sctp_retransmit(&asoc->outqueue, t, SCTP_RTXR_PMTUD);
 }
 


Patches currently in stable-queue which might be from marcelo.leitner@gmail.com are

queue-4.14/sctp-do-not-retransmit-upon-fragneeded-if-pmtu-discovery-is-disabled.patch
queue-4.14/sctp-fix-the-handling-of-icmp-frag-needed-for-too-small-mtus.patch

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2018-01-13  9:52 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-01-13  9:52 Patch "sctp: do not retransmit upon FragNeeded if PMTU discovery is disabled" has been added to the 4.14-stable tree gregkh

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.