All of lore.kernel.org
 help / color / mirror / Atom feed
From: Vlad Yasevich <vyasevich@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: xufengzhang.main@gmail.com, sri@us.ibm.com, davem@davemloft.net,
	linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sctp: set association state to established in dupcook_a handler
Date: Wed, 23 Jan 2013 14:22:16 +0000	[thread overview]
Message-ID: <50FFF218.1010204@gmail.com> (raw)
In-Reply-To: <20130123134650.GA3512@hmsreliant.think-freely.org>

On 01/23/2013 08:46 AM, Neil Horman wrote:
> On Wed, Jan 23, 2013 at 03:38:40PM +0800, xufengzhang.main@gmail.com wrote:
>> From: Xufeng Zhang <xufeng.zhang@windriver.com>
>>
>> While sctp handling a duplicate COOKIE-ECHO and the action is
>> 'Association restart', sctp_sf_do_dupcook_a() will processing
>> the unexpected COOKIE-ECHO for peer restart, but it does not set
>> the association state to SCTP_STATE_ESTABLISHED, so the association
>> could stuck in SCTP_STATE_SHUTDOWN_PENDING state forever.
>> This violates the sctp specification:
>>    RFC 4960 5.2.4. Handle a COOKIE ECHO when a TCB Exists
>>    Action
>>    A) In this case, the peer may have restarted. .....
>>       After this, the endpoint shall enter the ESTABLISHED state.
>>
>> Fix this problem by adding a SCTP_CMD_NEW_STATE cmd to the command
>> list so as to set the restart association to SCTP_STATE_ESTABLISHED
>> state properly.
>>
>> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
>> ---
>>   net/sctp/sm_statefuns.c |    2 ++
>>   1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>> index 618ec7e..528f1c8 100644
>> --- a/net/sctp/sm_statefuns.c
>> +++ b/net/sctp/sm_statefuns.c
>> @@ -1779,6 +1779,8 @@ static sctp_disposition_t sctp_sf_do_dupcook_a(struct net *net,
>>
>>   	/* Update the content of current association. */
>>   	sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC, SCTP_ASOC(new_asoc));
>> +	sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
>> +			SCTP_STATE(SCTP_STATE_ESTABLISHED));
>>   	sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
>>   	sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(ev));
>>   	return SCTP_DISPOSITION_CONSUME;
>> --
>> 1.7.0.2
>>
>>
>
> Looks reasonable to me, thanks
>
> nit: The RFC indicate the association should enter the ESTABLISHED state after
> preforming all other actions, so it seems that the state change should occur
> after the ULP event is sent
>

I have a slight concern here that if we change state last, then any data 
that may have been bundled with COOKIE-ACK as part of CMD_REPLY will get 
the SACK_IMMEDIATE flag set since we are still in the SHUTDOWN_PENDING 
state.

I would be more correct (and would match sctp_sf_do_5_1D_ce) to
do it in this order:
   UPDATE_ASSOC  - resets all the congestion/association variables
   EVENT_UP  - send RESTART to USER
   NEW_STATE  - set ESTABLISHED state (as per spec)
   REPLY	- Send cookie-ack along with any pending data.

-vlad
> Neil
>


WARNING: multiple messages have this Message-ID (diff)
From: Vlad Yasevich <vyasevich@gmail.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: xufengzhang.main@gmail.com, sri@us.ibm.com, davem@davemloft.net,
	linux-sctp@vger.kernel.org, netdev@vger.kernel.org,
	linux-kernel@vger.kernel.org
Subject: Re: [PATCH] sctp: set association state to established in dupcook_a handler
Date: Wed, 23 Jan 2013 09:22:16 -0500	[thread overview]
Message-ID: <50FFF218.1010204@gmail.com> (raw)
In-Reply-To: <20130123134650.GA3512@hmsreliant.think-freely.org>

On 01/23/2013 08:46 AM, Neil Horman wrote:
> On Wed, Jan 23, 2013 at 03:38:40PM +0800, xufengzhang.main@gmail.com wrote:
>> From: Xufeng Zhang <xufeng.zhang@windriver.com>
>>
>> While sctp handling a duplicate COOKIE-ECHO and the action is
>> 'Association restart', sctp_sf_do_dupcook_a() will processing
>> the unexpected COOKIE-ECHO for peer restart, but it does not set
>> the association state to SCTP_STATE_ESTABLISHED, so the association
>> could stuck in SCTP_STATE_SHUTDOWN_PENDING state forever.
>> This violates the sctp specification:
>>    RFC 4960 5.2.4. Handle a COOKIE ECHO when a TCB Exists
>>    Action
>>    A) In this case, the peer may have restarted. .....
>>       After this, the endpoint shall enter the ESTABLISHED state.
>>
>> Fix this problem by adding a SCTP_CMD_NEW_STATE cmd to the command
>> list so as to set the restart association to SCTP_STATE_ESTABLISHED
>> state properly.
>>
>> Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
>> ---
>>   net/sctp/sm_statefuns.c |    2 ++
>>   1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
>> index 618ec7e..528f1c8 100644
>> --- a/net/sctp/sm_statefuns.c
>> +++ b/net/sctp/sm_statefuns.c
>> @@ -1779,6 +1779,8 @@ static sctp_disposition_t sctp_sf_do_dupcook_a(struct net *net,
>>
>>   	/* Update the content of current association. */
>>   	sctp_add_cmd_sf(commands, SCTP_CMD_UPDATE_ASSOC, SCTP_ASOC(new_asoc));
>> +	sctp_add_cmd_sf(commands, SCTP_CMD_NEW_STATE,
>> +			SCTP_STATE(SCTP_STATE_ESTABLISHED));
>>   	sctp_add_cmd_sf(commands, SCTP_CMD_REPLY, SCTP_CHUNK(repl));
>>   	sctp_add_cmd_sf(commands, SCTP_CMD_EVENT_ULP, SCTP_ULPEVENT(ev));
>>   	return SCTP_DISPOSITION_CONSUME;
>> --
>> 1.7.0.2
>>
>>
>
> Looks reasonable to me, thanks
>
> nit: The RFC indicate the association should enter the ESTABLISHED state after
> preforming all other actions, so it seems that the state change should occur
> after the ULP event is sent
>

I have a slight concern here that if we change state last, then any data 
that may have been bundled with COOKIE-ACK as part of CMD_REPLY will get 
the SACK_IMMEDIATE flag set since we are still in the SHUTDOWN_PENDING 
state.

I would be more correct (and would match sctp_sf_do_5_1D_ce) to
do it in this order:
   UPDATE_ASSOC  - resets all the congestion/association variables
   EVENT_UP  - send RESTART to USER
   NEW_STATE  - set ESTABLISHED state (as per spec)
   REPLY	- Send cookie-ack along with any pending data.

-vlad
> Neil
>


  reply	other threads:[~2013-01-23 14:22 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-23  7:38 [PATCH] sctp: set association state to established in dupcook_a handler xufengzhang.main
2013-01-23  7:38 ` xufengzhang.main
2013-01-23 13:46 ` Neil Horman
2013-01-23 13:46   ` Neil Horman
2013-01-23 14:22   ` Vlad Yasevich [this message]
2013-01-23 14:22     ` Vlad Yasevich
2013-01-24  1:36     ` Xufeng Zhang
2013-01-24  1:36       ` Xufeng Zhang
2013-01-24  1:34   ` Xufeng Zhang
2013-01-24  1:34     ` Xufeng Zhang
  -- strict thread matches above, loose matches on Subject: below --
2013-06-03  7:52 Xufeng Zhang
2013-06-03 14:28 ` Greg KH
2013-06-04  2:00   ` Xufeng Zhang
2013-06-05  0:13     ` Ben Hutchings
2013-06-05  2:20       ` Xufeng Zhang
2013-06-05  2:55 ` Xufeng Zhang
2013-06-07 10:39   ` Xufeng Zhang

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=50FFF218.1010204@gmail.com \
    --to=vyasevich@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-sctp@vger.kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=nhorman@tuxdriver.com \
    --cc=sri@us.ibm.com \
    --cc=xufengzhang.main@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 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.