From: Thomas Graf <tgraf@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Vladislav Yasevich <vladislav.yasevich@hp.com>,
netdev@vger.kernel.org, davem@davemloft.net,
Wei Yongjun <yjwei@cn.fujitsu.com>,
Sridhar Samudrala <sri@us.ibm.com>,
linux-sctp@vger.kernel.org
Subject: Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
Date: Wed, 06 Jul 2011 13:16:24 +0000 [thread overview]
Message-ID: <1309958184.12098.111.camel@lsx> (raw)
In-Reply-To: <20110706121508.GA19518@hmsreliant.think-freely.org>
On Wed, 2011-07-06 at 08:15 -0400, Neil Horman wrote:
> On Mon, Jul 04, 2011 at 09:50:19AM -0400, Thomas Graf wrote:
> > --- a/net/sctp/sm_statefuns.c
> > +++ b/net/sctp/sm_statefuns.c
> > @@ -5154,7 +5154,7 @@ sctp_disposition_t sctp_sf_do_9_2_start_shutdown(
> > * The sender of the SHUTDOWN MAY also start an overall guard timer
> > * 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
> > */
> > - sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_START,
> > + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
> > SCTP_TO(SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD));
> >
> How come you're modifying this chunk to use TIMER_RESTART rather than
> TIMER_START? start shutdown is where the t5 timer is actually started, isn't it?
Since we also start the timer in SHUTDOWN_PENDING now if we hit
the retransmission limit the timer may be running already and
needs to be restarted (at least in theory).
In reality the timer should be stopped though, we can only go
from SHUTDOWN_PENDING into SHUTDOWN by actually SACKing bytes which
will delete the timer. This may change though and I did not want
this to bite us later on.
WARNING: multiple messages have this Message-ID (diff)
From: Thomas Graf <tgraf@redhat.com>
To: Neil Horman <nhorman@tuxdriver.com>
Cc: Vladislav Yasevich <vladislav.yasevich@hp.com>,
netdev@vger.kernel.org, davem@davemloft.net,
Wei Yongjun <yjwei@cn.fujitsu.com>,
Sridhar Samudrala <sri@us.ibm.com>,
linux-sctp@vger.kernel.org
Subject: Re: [PATCHv2] sctp: Enforce retransmission limit during shutdown
Date: Wed, 06 Jul 2011 15:16:24 +0200 [thread overview]
Message-ID: <1309958184.12098.111.camel@lsx> (raw)
In-Reply-To: <20110706121508.GA19518@hmsreliant.think-freely.org>
On Wed, 2011-07-06 at 08:15 -0400, Neil Horman wrote:
> On Mon, Jul 04, 2011 at 09:50:19AM -0400, Thomas Graf wrote:
> > --- a/net/sctp/sm_statefuns.c
> > +++ b/net/sctp/sm_statefuns.c
> > @@ -5154,7 +5154,7 @@ sctp_disposition_t sctp_sf_do_9_2_start_shutdown(
> > * The sender of the SHUTDOWN MAY also start an overall guard timer
> > * 'T5-shutdown-guard' to bound the overall time for shutdown sequence.
> > */
> > - sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_START,
> > + sctp_add_cmd_sf(commands, SCTP_CMD_TIMER_RESTART,
> > SCTP_TO(SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD));
> >
> How come you're modifying this chunk to use TIMER_RESTART rather than
> TIMER_START? start shutdown is where the t5 timer is actually started, isn't it?
Since we also start the timer in SHUTDOWN_PENDING now if we hit
the retransmission limit the timer may be running already and
needs to be restarted (at least in theory).
In reality the timer should be stopped though, we can only go
from SHUTDOWN_PENDING into SHUTDOWN by actually SACKing bytes which
will delete the timer. This may change though and I did not want
this to bite us later on.
next prev parent reply other threads:[~2011-07-06 13:16 UTC|newest]
Thread overview: 68+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-29 13:57 [PATCH] sctp: Enforce maximum retransmissions during shutdown Thomas Graf
2011-06-29 13:57 ` Thomas Graf
2011-06-29 14:20 ` Vladislav Yasevich
2011-06-29 14:20 ` Vladislav Yasevich
2011-06-29 14:36 ` Thomas Graf
2011-06-29 14:36 ` Thomas Graf
2011-06-29 14:58 ` Vladislav Yasevich
2011-06-29 14:58 ` Vladislav Yasevich
2011-06-29 15:48 ` Thomas Graf
2011-06-29 15:48 ` Thomas Graf
2011-06-29 16:14 ` Vladislav Yasevich
2011-06-29 16:14 ` Vladislav Yasevich
2011-06-30 8:49 ` Thomas Graf
2011-06-30 8:49 ` Thomas Graf
2011-06-30 14:08 ` Vladislav Yasevich
2011-06-30 14:08 ` Vladislav Yasevich
2011-06-30 16:17 ` Thomas Graf
2011-06-30 16:17 ` Thomas Graf
2011-07-04 13:50 ` [PATCHv2] sctp: Enforce retransmission limit " Thomas Graf
2011-07-04 13:50 ` Thomas Graf
2011-07-06 7:24 ` David Miller
2011-07-06 7:24 ` David Miller
2011-07-06 12:15 ` Neil Horman
2011-07-06 12:15 ` Neil Horman
2011-07-06 13:16 ` Thomas Graf [this message]
2011-07-06 13:16 ` Thomas Graf
2011-07-06 14:19 ` Neil Horman
2011-07-06 14:19 ` Neil Horman
2011-07-06 13:42 ` Vladislav Yasevich
2011-07-06 13:42 ` Vladislav Yasevich
2011-07-06 14:18 ` Thomas Graf
2011-07-06 14:18 ` Thomas Graf
2011-07-06 14:31 ` Vladislav Yasevich
2011-07-06 14:31 ` Vladislav Yasevich
2011-07-06 15:49 ` Thomas Graf
2011-07-06 15:49 ` Thomas Graf
2011-07-06 16:23 ` Vladislav Yasevich
2011-07-06 16:23 ` Vladislav Yasevich
2011-07-06 21:58 ` Thomas Graf
2011-07-06 21:58 ` Thomas Graf
2011-07-07 10:28 ` [PATCHv3] " Thomas Graf
2011-07-07 10:28 ` Thomas Graf
2011-07-07 13:36 ` Vladislav Yasevich
2011-07-07 13:36 ` Vladislav Yasevich
2011-07-07 21:09 ` David Miller
2011-07-07 21:09 ` David Miller
2011-06-30 13:31 ` [PATCH] sctp: ABORT if receive queue is not empty while closing Thomas Graf
2011-06-30 13:31 ` [PATCH] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-06-30 14:11 ` [PATCH] sctp: ABORT if receive queue is not empty while closing Vladislav Yasevich
2011-06-30 14:11 ` [PATCH] sctp: ABORT if receive queue is not empty while closing socket Vladislav Yasevich
2011-06-30 16:19 ` [PATCH] sctp: ABORT if receive queue is not empty while closing Thomas Graf
2011-06-30 16:19 ` [PATCH] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-06-30 16:27 ` [PATCH] sctp: ABORT if receive queue is not empty while closing Vladislav Yasevich
2011-06-30 16:27 ` [PATCH] sctp: ABORT if receive queue is not empty while closing socket Vladislav Yasevich
2011-07-08 10:57 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing Thomas Graf
2011-07-08 10:57 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-07-08 13:49 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing Vladislav Yasevich
2011-07-08 13:49 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing socket Vladislav Yasevich
2011-07-08 14:29 ` [PATCHv2] sctp: ABORT if receive queue is not empty while Thomas Graf
2011-07-08 14:29 ` [PATCHv2] sctp: ABORT if receive queue is not empty while closing socket Thomas Graf
2011-07-08 14:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is Thomas Graf
2011-07-08 14:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket Thomas Graf
2011-07-08 16:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering David Miller
2011-07-08 16:37 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket David Miller
2011-07-08 16:43 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue Vladislav Yasevich
2011-07-08 16:43 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket Vladislav Yasevich
2011-07-08 16:53 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering David Miller
2011-07-08 16:53 ` [PATCHv3] sctp: ABORT if receive, reassmbly, or reodering queue is not empty while closing socket 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=1309958184.12098.111.camel@lsx \
--to=tgraf@redhat.com \
--cc=davem@davemloft.net \
--cc=linux-sctp@vger.kernel.org \
--cc=netdev@vger.kernel.org \
--cc=nhorman@tuxdriver.com \
--cc=sri@us.ibm.com \
--cc=vladislav.yasevich@hp.com \
--cc=yjwei@cn.fujitsu.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.