netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
To: Xin Long <lucien.xin@gmail.com>
Cc: network dev <netdev@vger.kernel.org>,
	linux-sctp@vger.kernel.org, Neil Horman <nhorman@tuxdriver.com>,
	Vlad Yasevich <vyasevich@gmail.com>,
	davem@davemloft.net
Subject: Re: [PATCHv2 net-next 2/7] sctp: implement receiver-side procedures for the SSN/TSN Reset Request Parameter
Date: Mon, 20 Mar 2017 15:04:57 -0300	[thread overview]
Message-ID: <20170320180457.GD23553@localhost.localdomain> (raw)
In-Reply-To: <f224235b4621ea3a182e959873f6fe0ba78e5416.1489118815.git.lucien.xin@gmail.com>

On Fri, Mar 10, 2017 at 12:11:07PM +0800, Xin Long wrote:
> This patch is to implement Receiver-Side Procedures for the SSN/TSN
> Reset Request Parameter described in rfc6525 section 6.2.4.
> 
> The process is kind of complicate, it's wonth having some comments
> from section 6.2.4 in the codes.
> 
> Signed-off-by: Xin Long <lucien.xin@gmail.com>
> ---
>  include/net/sctp/sm.h   |  4 +++
>  net/sctp/sm_statefuns.c |  3 ++
>  net/sctp/stream.c       | 79 +++++++++++++++++++++++++++++++++++++++++++++++++
>  3 files changed, 86 insertions(+)
> 
> diff --git a/include/net/sctp/sm.h b/include/net/sctp/sm.h
> index b6f682e..2629d66 100644
> --- a/include/net/sctp/sm.h
> +++ b/include/net/sctp/sm.h
> @@ -293,6 +293,10 @@ struct sctp_chunk *sctp_process_strreset_inreq(
>  				struct sctp_association *asoc,
>  				union sctp_params param,
>  				struct sctp_ulpevent **evp);
> +struct sctp_chunk *sctp_process_strreset_tsnreq(
> +				struct sctp_association *asoc,
> +				union sctp_params param,
> +				struct sctp_ulpevent **evp);
>  
>  /* Prototypes for statetable processing. */
>  
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index e03bb1a..6982064 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -3872,6 +3872,9 @@ sctp_disposition_t sctp_sf_do_reconf(struct net *net,
>  		else if (param.p->type == SCTP_PARAM_RESET_IN_REQUEST)
>  			reply = sctp_process_strreset_inreq(
>  				(struct sctp_association *)asoc, param, &ev);
> +		else if (param.p->type == SCTP_PARAM_RESET_TSN_REQUEST)
> +			reply = sctp_process_strreset_tsnreq(
> +				(struct sctp_association *)asoc, param, &ev);
>  		/* More handles for other types will be added here, by now it
>  		 * just ignores other types.
>  		 */
> diff --git a/net/sctp/stream.c b/net/sctp/stream.c
> index 1c6cc04..7e993b0 100644
> --- a/net/sctp/stream.c
> +++ b/net/sctp/stream.c
> @@ -477,3 +477,82 @@ struct sctp_chunk *sctp_process_strreset_inreq(
>  
>  	return chunk;
>  }
> +
> +struct sctp_chunk *sctp_process_strreset_tsnreq(
> +				struct sctp_association *asoc,
> +				union sctp_params param,
> +				struct sctp_ulpevent **evp)
> +{
> +	__u32 init_tsn = 0, next_tsn = 0, max_tsn_seen;
> +	struct sctp_strreset_tsnreq *tsnreq = param.v;
> +	struct sctp_stream *stream = asoc->stream;
> +	__u32 result = SCTP_STRRESET_DENIED;
> +	__u32 request_seq;
> +	__u16 i;
> +
> +	request_seq = ntohl(tsnreq->request_seq);
> +	if (request_seq > asoc->strreset_inseq) {
> +		result = SCTP_STRRESET_ERR_BAD_SEQNO;
> +		goto out;
> +	} else if (request_seq == asoc->strreset_inseq) {
> +		asoc->strreset_inseq++;
> +	}

I guess I already asked this, but.. why request_seq <
asoc->strreset_inseq is allowed?

> +
> +	if (!(asoc->strreset_enable & SCTP_ENABLE_RESET_ASSOC_REQ))
> +		goto out;
> +
> +	if (asoc->strreset_outstanding) {
> +		result = SCTP_STRRESET_ERR_IN_PROGRESS;
> +		goto out;
> +	}
> +
> +	/* G3: The same processing as though a SACK chunk with no gap report
> +	 *     and a cumulative TSN ACK of the Sender's Next TSN minus 1 were
> +	 *     received MUST be performed.
> +	 */
> +	max_tsn_seen = sctp_tsnmap_get_max_tsn_seen(&asoc->peer.tsn_map);
> +	sctp_ulpq_reasm_flushtsn(&asoc->ulpq, max_tsn_seen);
> +	sctp_ulpq_abort_pd(&asoc->ulpq, GFP_ATOMIC);
> +
> +	/* G1: Compute an appropriate value for the Receiver's Next TSN -- the
> +	 *     TSN that the peer should use to send the next DATA chunk.  The
> +	 *     value SHOULD be the smallest TSN not acknowledged by the
> +	 *     receiver of the request plus 2^31.
> +	 */
> +	init_tsn = sctp_tsnmap_get_ctsn(&asoc->peer.tsn_map) + (1 << 31);
> +	sctp_tsnmap_init(&asoc->peer.tsn_map, SCTP_TSN_MAP_INITIAL,
> +			 init_tsn, GFP_ATOMIC);
> +
> +	/* G4: The same processing as though a FWD-TSN chunk (as defined in
> +	 *     [RFC3758]) with all streams affected and a new cumulative TSN
> +	 *     ACK of the Receiver's Next TSN minus 1 were received MUST be
> +	 *     performed.
> +	 */
> +	sctp_outq_free(&asoc->outqueue);
> +
> +	/* G2: Compute an appropriate value for the local endpoint's next TSN,
> +	 *     i.e., the next TSN assigned by the receiver of the SSN/TSN reset
> +	 *     chunk.  The value SHOULD be the highest TSN sent by the receiver
> +	 *     of the request plus 1.
> +	 */
> +	next_tsn = asoc->next_tsn;
> +	asoc->ctsn_ack_point = next_tsn - 1;
> +	asoc->adv_peer_ack_point = asoc->ctsn_ack_point;
> +
> +	/* G5:  The next expected and outgoing SSNs MUST be reset to 0 for all
> +	 *      incoming and outgoing streams.
> +	 */
> +	for (i = 0; i < stream->outcnt; i++)
> +		stream->out[i].ssn = 0;
> +	for (i = 0; i < stream->incnt; i++)
> +		stream->in[i].ssn = 0;
> +
> +	result = SCTP_STRRESET_PERFORMED;
> +
> +	*evp = sctp_ulpevent_make_assoc_reset_event(asoc, 0, init_tsn,
> +						    next_tsn, GFP_ATOMIC);
> +
> +out:
> +	return sctp_make_strreset_tsnresp(asoc, result, request_seq,
> +					  next_tsn, init_tsn);
> +}
> -- 
> 2.1.0
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

  parent reply	other threads:[~2017-03-20 18:07 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-10  4:11 [PATCHv2 net-next 0/7] sctp: add receiver-side procedures for stream reconf asoc reset and add streams and response Xin Long
2017-03-10  4:11 ` [PATCHv2 net-next 1/7] sctp: add support for generating assoc reset event notification Xin Long
2017-03-10  4:11   ` [PATCHv2 net-next 2/7] sctp: implement receiver-side procedures for the SSN/TSN Reset Request Parameter Xin Long
2017-03-10  4:11     ` [PATCHv2 net-next 3/7] sctp: add support for generating add stream change event notification Xin Long
2017-03-10  4:11       ` [PATCHv2 net-next 4/7] sctp: implement receiver-side procedures for the Add Outgoing Streams Request Parameter Xin Long
2017-03-10  4:11         ` [PATCHv2 net-next 5/7] sctp: implement receiver-side procedures for the Add Incoming " Xin Long
2017-03-10  4:11           ` [PATCHv2 net-next 6/7] sctp: implement receiver-side procedures for the Reconf Response Parameter Xin Long
2017-03-10  4:11             ` [PATCHv2 net-next 7/7] sctp: add get and set sockopt for reconf_enable Xin Long
2017-03-20 18:04     ` Marcelo Ricardo Leitner [this message]
2017-03-21  5:44       ` [PATCHv2 net-next 2/7] sctp: implement receiver-side procedures for the SSN/TSN Reset Request Parameter Xin Long
2017-03-24 23:52         ` Marcelo Ricardo Leitner
2017-03-27  4:48           ` Xin Long
2017-03-27 14:16             ` Marcelo Ricardo Leitner
2017-03-27 15:50               ` Xin Long
2017-03-10  4:17 ` [PATCHv2 net-next 0/7] sctp: add receiver-side procedures for stream reconf asoc reset and add streams and response Xin Long
2017-03-13  6:22 ` David Miller

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170320180457.GD23553@localhost.localdomain \
    --to=marcelo.leitner@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-sctp@vger.kernel.org \
    --cc=lucien.xin@gmail.com \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=vyasevich@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).