diff mbox series

[v2] sctp: do trace_sctp_probe after SACK validation and check

Message ID 20191224104040.511-1-qdkevin.kou@gmail.com
State Changes Requested
Delegated to: David Miller
Headers show
Series [v2] sctp: do trace_sctp_probe after SACK validation and check | expand

Commit Message

Kevin Kou Dec. 24, 2019, 10:40 a.m. UTC
The function sctp_sf_eat_sack_6_2 now performs the Verification
Tag validation, Chunk length validation, Bogu check, and also
the detection of out-of-order SACK based on the RFC2960
Section 6.2 at the beginning, and finally performs the further
processing of SACK. The trace_sctp_probe now triggered before
the above necessary validation and check.

this patch is to do the trace_sctp_probe after the chunk sanity
tests, but keep doing trace if the SACK received is out of order,
for the out-of-order SACK is valuable to congestion control
debugging.

v1->v2:
 - keep doing SCTP trace if the SACK is out of order as Marcelo's
   suggestion.

Signed-off-by: Kevin Kou <qdkevin.kou@gmail.com>
---
 net/sctp/sm_statefuns.c | 18 +++++++++---------
 1 file changed, 9 insertions(+), 9 deletions(-)

Comments

Marcelo Ricardo Leitner Dec. 24, 2019, 1:16 p.m. UTC | #1
On Tue, Dec 24, 2019 at 10:40:40AM +0000, Kevin Kou wrote:
> The function sctp_sf_eat_sack_6_2 now performs the Verification
> Tag validation, Chunk length validation, Bogu check, and also
> the detection of out-of-order SACK based on the RFC2960
> Section 6.2 at the beginning, and finally performs the further
> processing of SACK. The trace_sctp_probe now triggered before
> the above necessary validation and check.
> 
> this patch is to do the trace_sctp_probe after the chunk sanity
> tests, but keep doing trace if the SACK received is out of order,
> for the out-of-order SACK is valuable to congestion control
> debugging.
> 
> v1->v2:
>  - keep doing SCTP trace if the SACK is out of order as Marcelo's
>    suggestion.

Thanks, but you generated the v2 on top of v1. You need to generate
the patch as if v1 didn't get applied (because it is not going in).

For future reference, if it would be a follow-up, then it wouldn't be
a "v2"..

And you need to explicit tag the patch with 'net' or 'net-next',
indicating which tree you target. net is for fixes, net-next for
cleanups/new features. net-next is good here.

Thanks,
Marcelo

> 
> Signed-off-by: Kevin Kou <qdkevin.kou@gmail.com>
> ---
>  net/sctp/sm_statefuns.c | 18 +++++++++---------
>  1 file changed, 9 insertions(+), 9 deletions(-)
> 
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index b4a54df..d302a78 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -3298,6 +3298,15 @@ enum sctp_disposition sctp_sf_eat_sack_6_2(struct net *net,
>  	chunk->subh.sack_hdr = sackh;
>  	ctsn = ntohl(sackh->cum_tsn_ack);
>  
> +	/* If Cumulative TSN Ack beyond the max tsn currently
> +	 * send, terminating the association and respond to the
> +	 * sender with an ABORT.
> +	 */
> +	if (TSN_lte(asoc->next_tsn, ctsn))
> +		return sctp_sf_violation_ctsn(net, ep, asoc, type, arg, commands);
> +
> +	trace_sctp_probe(ep, asoc, chunk);
> +
>  	/* i) If Cumulative TSN Ack is less than the Cumulative TSN
>  	 *     Ack Point, then drop the SACK.  Since Cumulative TSN
>  	 *     Ack is monotonically increasing, a SACK whose
> @@ -3311,15 +3320,6 @@ enum sctp_disposition sctp_sf_eat_sack_6_2(struct net *net,
>  		return SCTP_DISPOSITION_DISCARD;
>  	}
>  
> -	/* If Cumulative TSN Ack beyond the max tsn currently
> -	 * send, terminating the association and respond to the
> -	 * sender with an ABORT.
> -	 */
> -	if (!TSN_lt(ctsn, asoc->next_tsn))
> -		return sctp_sf_violation_ctsn(net, ep, asoc, type, arg, commands);
> -
> -	trace_sctp_probe(ep, asoc, chunk);
> -
>  	/* Return this SACK for further processing.  */
>  	sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_CHUNK(chunk));
>  
> -- 
> 1.8.3.1
>
diff mbox series

Patch

diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
index b4a54df..d302a78 100644
--- a/net/sctp/sm_statefuns.c
+++ b/net/sctp/sm_statefuns.c
@@ -3298,6 +3298,15 @@  enum sctp_disposition sctp_sf_eat_sack_6_2(struct net *net,
 	chunk->subh.sack_hdr = sackh;
 	ctsn = ntohl(sackh->cum_tsn_ack);
 
+	/* If Cumulative TSN Ack beyond the max tsn currently
+	 * send, terminating the association and respond to the
+	 * sender with an ABORT.
+	 */
+	if (TSN_lte(asoc->next_tsn, ctsn))
+		return sctp_sf_violation_ctsn(net, ep, asoc, type, arg, commands);
+
+	trace_sctp_probe(ep, asoc, chunk);
+
 	/* i) If Cumulative TSN Ack is less than the Cumulative TSN
 	 *     Ack Point, then drop the SACK.  Since Cumulative TSN
 	 *     Ack is monotonically increasing, a SACK whose
@@ -3311,15 +3320,6 @@  enum sctp_disposition sctp_sf_eat_sack_6_2(struct net *net,
 		return SCTP_DISPOSITION_DISCARD;
 	}
 
-	/* If Cumulative TSN Ack beyond the max tsn currently
-	 * send, terminating the association and respond to the
-	 * sender with an ABORT.
-	 */
-	if (!TSN_lt(ctsn, asoc->next_tsn))
-		return sctp_sf_violation_ctsn(net, ep, asoc, type, arg, commands);
-
-	trace_sctp_probe(ep, asoc, chunk);
-
 	/* Return this SACK for further processing.  */
 	sctp_add_cmd_sf(commands, SCTP_CMD_PROCESS_SACK, SCTP_CHUNK(chunk));