2008-01-11 14:57:09 +00:00
|
|
|
/* SCTP kernel implementation
|
2005-04-16 22:20:36 +00:00
|
|
|
* (C) Copyright IBM Corp. 2001, 2004
|
|
|
|
* Copyright (c) 1999-2000 Cisco, Inc.
|
|
|
|
* Copyright (c) 1999-2001 Motorola, Inc.
|
|
|
|
* Copyright (c) 2001 Intel Corp.
|
|
|
|
* Copyright (c) 2001 La Monte H.P. Yarroll
|
|
|
|
*
|
2008-01-11 14:57:09 +00:00
|
|
|
* This file is part of the SCTP kernel implementation
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* This module provides the abstraction for an SCTP association.
|
|
|
|
*
|
2008-01-11 14:57:09 +00:00
|
|
|
* This SCTP implementation is free software;
|
2005-04-16 22:20:36 +00:00
|
|
|
* you can redistribute it and/or modify it under the terms of
|
|
|
|
* the GNU General Public License as published by
|
|
|
|
* the Free Software Foundation; either version 2, or (at your option)
|
|
|
|
* any later version.
|
|
|
|
*
|
2008-01-11 14:57:09 +00:00
|
|
|
* This SCTP implementation is distributed in the hope that it
|
2005-04-16 22:20:36 +00:00
|
|
|
* will be useful, but WITHOUT ANY WARRANTY; without even the implied
|
|
|
|
* ************************
|
|
|
|
* warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
|
|
|
|
* See the GNU General Public License for more details.
|
|
|
|
*
|
|
|
|
* You should have received a copy of the GNU General Public License
|
2013-12-06 14:28:48 +00:00
|
|
|
* along with GNU CC; see the file COPYING. If not, see
|
|
|
|
* <http://www.gnu.org/licenses/>.
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Please send any bug reports or fixes you make to the
|
|
|
|
* email address(es):
|
2013-07-23 12:51:47 +00:00
|
|
|
* lksctp developers <linux-sctp@vger.kernel.org>
|
2005-04-16 22:20:36 +00:00
|
|
|
*
|
|
|
|
* Written or modified by:
|
|
|
|
* La Monte H.P. Yarroll <piggy@acm.org>
|
|
|
|
* Karl Knutson <karl@athena.chicago.il.us>
|
|
|
|
* Jon Grimm <jgrimm@us.ibm.com>
|
|
|
|
* Xingang Guo <xingang.guo@intel.com>
|
|
|
|
* Hui Huang <hui.huang@nokia.com>
|
|
|
|
* Sridhar Samudrala <sri@us.ibm.com>
|
|
|
|
* Daisy Chang <daisyc@us.ibm.com>
|
|
|
|
* Ryan Layer <rmlayer@us.ibm.com>
|
|
|
|
* Kevin Gao <kevin.gao@intel.com>
|
|
|
|
*/
|
|
|
|
|
2010-08-24 13:21:08 +00:00
|
|
|
#define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
#include <linux/types.h>
|
|
|
|
#include <linux/fcntl.h>
|
|
|
|
#include <linux/poll.h>
|
|
|
|
#include <linux/init.h>
|
|
|
|
|
|
|
|
#include <linux/slab.h>
|
|
|
|
#include <linux/in.h>
|
|
|
|
#include <net/ipv6.h>
|
|
|
|
#include <net/sctp/sctp.h>
|
|
|
|
#include <net/sctp/sm.h>
|
|
|
|
|
|
|
|
/* Forward declarations for internal functions. */
|
2014-06-11 16:19:29 +00:00
|
|
|
static void sctp_select_active_and_retran_path(struct sctp_association *asoc);
|
2006-11-22 14:57:56 +00:00
|
|
|
static void sctp_assoc_bh_rcv(struct work_struct *work);
|
2007-12-20 22:11:47 +00:00
|
|
|
static void sctp_assoc_free_asconf_acks(struct sctp_association *asoc);
|
2011-05-24 21:48:02 +00:00
|
|
|
static void sctp_assoc_free_asconf_queue(struct sctp_association *asoc);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* 1st Level Abstractions. */
|
|
|
|
|
|
|
|
/* Initialize a new association from provided memory. */
|
|
|
|
static struct sctp_association *sctp_association_init(struct sctp_association *asoc,
|
|
|
|
const struct sctp_endpoint *ep,
|
|
|
|
const struct sock *sk,
|
|
|
|
sctp_scope_t scope,
|
2005-10-07 06:46:04 +00:00
|
|
|
gfp_t gfp)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2012-08-07 07:29:57 +00:00
|
|
|
struct net *net = sock_net(sk);
|
2005-04-16 22:20:36 +00:00
|
|
|
struct sctp_sock *sp;
|
|
|
|
int i;
|
2007-09-17 02:31:35 +00:00
|
|
|
sctp_paramhdr_t *p;
|
|
|
|
int err;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Retrieve the SCTP per socket area. */
|
|
|
|
sp = sctp_sk((struct sock *)sk);
|
|
|
|
|
|
|
|
/* Discarding const is appropriate here. */
|
|
|
|
asoc->ep = (struct sctp_endpoint *)ep;
|
|
|
|
asoc->base.sk = (struct sock *)sk;
|
2013-06-14 16:24:07 +00:00
|
|
|
|
|
|
|
sctp_endpoint_hold(asoc->ep);
|
2005-04-16 22:20:36 +00:00
|
|
|
sock_hold(asoc->base.sk);
|
|
|
|
|
|
|
|
/* Initialize the common base substructure. */
|
|
|
|
asoc->base.type = SCTP_EP_TYPE_ASSOCIATION;
|
|
|
|
|
|
|
|
/* Initialize the object handling fields. */
|
|
|
|
atomic_set(&asoc->base.refcnt, 1);
|
|
|
|
|
|
|
|
/* Initialize the bind addr area. */
|
|
|
|
sctp_bind_addr_init(&asoc->base.bind_addr, ep->base.bind_addr.port);
|
|
|
|
|
|
|
|
asoc->state = SCTP_STATE_CLOSED;
|
2013-06-25 16:17:27 +00:00
|
|
|
asoc->cookie_life = ms_to_ktime(sp->assocparams.sasoc_cookie_life);
|
2009-09-04 22:21:00 +00:00
|
|
|
asoc->user_frag = sp->user_frag;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Set the association max_retrans and RTO values from the
|
|
|
|
* socket values.
|
|
|
|
*/
|
|
|
|
asoc->max_retrans = sp->assocparams.sasoc_asocmaxrxt;
|
2012-08-07 07:29:57 +00:00
|
|
|
asoc->pf_retrans = net->sctp.pf_retrans;
|
2012-07-21 07:56:07 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
asoc->rto_initial = msecs_to_jiffies(sp->rtoinfo.srto_initial);
|
|
|
|
asoc->rto_max = msecs_to_jiffies(sp->rtoinfo.srto_max);
|
|
|
|
asoc->rto_min = msecs_to_jiffies(sp->rtoinfo.srto_min);
|
|
|
|
|
2005-12-22 19:36:46 +00:00
|
|
|
/* Initialize the association's heartbeat interval based on the
|
|
|
|
* sock configured value.
|
|
|
|
*/
|
|
|
|
asoc->hbinterval = msecs_to_jiffies(sp->hbinterval);
|
|
|
|
|
|
|
|
/* Initialize path max retrans value. */
|
|
|
|
asoc->pathmaxrxt = sp->pathmaxrxt;
|
|
|
|
|
|
|
|
/* Initialize default path MTU. */
|
|
|
|
asoc->pathmtu = sp->pathmtu;
|
|
|
|
|
|
|
|
/* Set association default SACK delay */
|
|
|
|
asoc->sackdelay = msecs_to_jiffies(sp->sackdelay);
|
2008-05-09 22:13:26 +00:00
|
|
|
asoc->sackfreq = sp->sackfreq;
|
2005-12-22 19:36:46 +00:00
|
|
|
|
|
|
|
/* Set the association default flags controlling
|
|
|
|
* Heartbeat, SACK delay, and Path MTU Discovery.
|
|
|
|
*/
|
|
|
|
asoc->param_flags = sp->param_flags;
|
|
|
|
|
2013-12-06 01:36:30 +00:00
|
|
|
/* Initialize the maximum number of new data packets that can be sent
|
2005-04-16 22:20:36 +00:00
|
|
|
* in a burst.
|
|
|
|
*/
|
2007-03-23 18:34:36 +00:00
|
|
|
asoc->max_burst = sp->max_burst;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-11-12 00:06:16 +00:00
|
|
|
/* initialize association timers */
|
|
|
|
asoc->timeouts[SCTP_EVENT_TIMEOUT_T1_COOKIE] = asoc->rto_initial;
|
|
|
|
asoc->timeouts[SCTP_EVENT_TIMEOUT_T1_INIT] = asoc->rto_initial;
|
|
|
|
asoc->timeouts[SCTP_EVENT_TIMEOUT_T2_SHUTDOWN] = asoc->rto_initial;
|
|
|
|
|
|
|
|
/* sctpimpguide Section 2.12.2
|
|
|
|
* If the 'T5-shutdown-guard' timer is used, it SHOULD be set to the
|
|
|
|
* recommended value of 5 times 'RTO.Max'.
|
|
|
|
*/
|
2007-02-09 14:25:18 +00:00
|
|
|
asoc->timeouts[SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD]
|
2005-11-12 00:06:16 +00:00
|
|
|
= 5 * asoc->rto_max;
|
|
|
|
|
2005-12-22 19:36:46 +00:00
|
|
|
asoc->timeouts[SCTP_EVENT_TIMEOUT_SACK] = asoc->sackdelay;
|
2013-12-10 11:48:15 +00:00
|
|
|
asoc->timeouts[SCTP_EVENT_TIMEOUT_AUTOCLOSE] = sp->autoclose * HZ;
|
2007-02-09 14:25:18 +00:00
|
|
|
|
2010-06-11 10:17:00 +00:00
|
|
|
/* Initializes the timers */
|
2008-01-24 05:20:07 +00:00
|
|
|
for (i = SCTP_EVENT_TIMEOUT_NONE; i < SCTP_NUM_TIMEOUT_TYPES; ++i)
|
|
|
|
setup_timer(&asoc->timers[i], sctp_timer_events[i],
|
|
|
|
(unsigned long)asoc);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Pull default initialization values from the sock options.
|
|
|
|
* Note: This assumes that the values have already been
|
|
|
|
* validated in the sock.
|
|
|
|
*/
|
|
|
|
asoc->c.sinit_max_instreams = sp->initmsg.sinit_max_instreams;
|
|
|
|
asoc->c.sinit_num_ostreams = sp->initmsg.sinit_num_ostreams;
|
|
|
|
asoc->max_init_attempts = sp->initmsg.sinit_max_attempts;
|
|
|
|
|
|
|
|
asoc->max_init_timeo =
|
|
|
|
msecs_to_jiffies(sp->initmsg.sinit_max_init_timeo);
|
|
|
|
|
|
|
|
/* Set the local window size for receive.
|
|
|
|
* This is also the rcvbuf space per association.
|
|
|
|
* RFC 6 - A SCTP receiver MUST be able to receive a minimum of
|
|
|
|
* 1500 bytes in one SCTP packet.
|
|
|
|
*/
|
2005-11-12 00:08:24 +00:00
|
|
|
if ((sk->sk_rcvbuf/2) < SCTP_DEFAULT_MINWINDOW)
|
2005-04-16 22:20:36 +00:00
|
|
|
asoc->rwnd = SCTP_DEFAULT_MINWINDOW;
|
|
|
|
else
|
2005-11-12 00:08:24 +00:00
|
|
|
asoc->rwnd = sk->sk_rcvbuf/2;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
asoc->a_rwnd = asoc->rwnd;
|
|
|
|
|
|
|
|
/* Use my own max window until I learn something better. */
|
|
|
|
asoc->peer.rwnd = SCTP_DEFAULT_MAXWINDOW;
|
|
|
|
|
2005-11-12 00:08:24 +00:00
|
|
|
/* Initialize the receive memory counter */
|
|
|
|
atomic_set(&asoc->rmem_alloc, 0);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
init_waitqueue_head(&asoc->wait);
|
|
|
|
|
|
|
|
asoc->c.my_vtag = sctp_generate_tag(ep);
|
|
|
|
asoc->c.my_port = ep->base.bind_addr.port;
|
|
|
|
|
|
|
|
asoc->c.initial_tsn = sctp_generate_tsn(ep);
|
|
|
|
|
|
|
|
asoc->next_tsn = asoc->c.initial_tsn;
|
|
|
|
|
|
|
|
asoc->ctsn_ack_point = asoc->next_tsn - 1;
|
|
|
|
asoc->adv_peer_ack_point = asoc->ctsn_ack_point;
|
|
|
|
asoc->highest_sacked = asoc->ctsn_ack_point;
|
|
|
|
asoc->last_cwr_tsn = asoc->ctsn_ack_point;
|
|
|
|
|
|
|
|
/* ADDIP Section 4.1 Asconf Chunk Procedures
|
|
|
|
*
|
|
|
|
* When an endpoint has an ASCONF signaled change to be sent to the
|
|
|
|
* remote endpoint it should do the following:
|
|
|
|
* ...
|
|
|
|
* A2) a serial number should be assigned to the chunk. The serial
|
|
|
|
* number SHOULD be a monotonically increasing number. The serial
|
|
|
|
* numbers SHOULD be initialized at the start of the
|
|
|
|
* association to the same value as the initial TSN.
|
|
|
|
*/
|
|
|
|
asoc->addip_serial = asoc->c.initial_tsn;
|
|
|
|
|
2005-07-09 04:47:49 +00:00
|
|
|
INIT_LIST_HEAD(&asoc->addip_chunk_list);
|
2007-12-20 22:11:47 +00:00
|
|
|
INIT_LIST_HEAD(&asoc->asconf_ack_list);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Make an empty list of remote transport addresses. */
|
|
|
|
INIT_LIST_HEAD(&asoc->peer.transport_addr_list);
|
|
|
|
|
|
|
|
/* RFC 2960 5.1 Normal Establishment of an Association
|
|
|
|
*
|
|
|
|
* After the reception of the first data chunk in an
|
|
|
|
* association the endpoint must immediately respond with a
|
|
|
|
* sack to acknowledge the data chunk. Subsequent
|
|
|
|
* acknowledgements should be done as described in Section
|
|
|
|
* 6.2.
|
|
|
|
*
|
|
|
|
* [We implement this by telling a new association that it
|
|
|
|
* already received one packet.]
|
|
|
|
*/
|
|
|
|
asoc->peer.sack_needed = 1;
|
2012-06-30 03:04:26 +00:00
|
|
|
asoc->peer.sack_generation = 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-10-24 21:24:26 +00:00
|
|
|
/* Assume that the peer will tell us if he recognizes ASCONF
|
|
|
|
* as part of INIT exchange.
|
2013-12-06 01:36:30 +00:00
|
|
|
* The sctp_addip_noauth option is there for backward compatibility
|
2007-10-24 21:24:26 +00:00
|
|
|
* and will revert old behavior.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2012-08-07 07:29:57 +00:00
|
|
|
if (net->sctp.addip_noauth)
|
2007-10-24 21:24:26 +00:00
|
|
|
asoc->peer.asconf_capable = 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Create an input queue. */
|
|
|
|
sctp_inq_init(&asoc->base.inqueue);
|
2006-11-22 14:57:56 +00:00
|
|
|
sctp_inq_set_th_handler(&asoc->base.inqueue, sctp_assoc_bh_rcv);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Create an output queue. */
|
|
|
|
sctp_outq_init(asoc, &asoc->outqueue);
|
|
|
|
|
|
|
|
if (!sctp_ulpq_init(&asoc->ulpq, asoc))
|
|
|
|
goto fail_init;
|
|
|
|
|
|
|
|
/* Assume that peer would support both address types unless we are
|
|
|
|
* told otherwise.
|
|
|
|
*/
|
|
|
|
asoc->peer.ipv4_address = 1;
|
2009-04-07 08:35:11 +00:00
|
|
|
if (asoc->base.sk->sk_family == PF_INET6)
|
|
|
|
asoc->peer.ipv6_address = 1;
|
2005-04-16 22:20:36 +00:00
|
|
|
INIT_LIST_HEAD(&asoc->asocs);
|
|
|
|
|
|
|
|
asoc->default_stream = sp->default_stream;
|
|
|
|
asoc->default_ppid = sp->default_ppid;
|
|
|
|
asoc->default_flags = sp->default_flags;
|
|
|
|
asoc->default_context = sp->default_context;
|
|
|
|
asoc->default_timetolive = sp->default_timetolive;
|
2006-12-14 00:34:22 +00:00
|
|
|
asoc->default_rcv_context = sp->default_rcv_context;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2007-09-17 02:31:35 +00:00
|
|
|
/* AUTH related initializations */
|
|
|
|
INIT_LIST_HEAD(&asoc->endpoint_shared_keys);
|
|
|
|
err = sctp_auth_asoc_copy_shkeys(ep, asoc, gfp);
|
|
|
|
if (err)
|
|
|
|
goto fail_init;
|
|
|
|
|
|
|
|
asoc->active_key_id = ep->active_key_id;
|
|
|
|
|
|
|
|
/* Save the hmacs and chunks list into this association */
|
|
|
|
if (ep->auth_hmacs_list)
|
|
|
|
memcpy(asoc->c.auth_hmacs, ep->auth_hmacs_list,
|
|
|
|
ntohs(ep->auth_hmacs_list->param_hdr.length));
|
|
|
|
if (ep->auth_chunk_list)
|
|
|
|
memcpy(asoc->c.auth_chunks, ep->auth_chunk_list,
|
|
|
|
ntohs(ep->auth_chunk_list->param_hdr.length));
|
|
|
|
|
|
|
|
/* Get the AUTH random number for this association */
|
|
|
|
p = (sctp_paramhdr_t *)asoc->c.auth_random;
|
|
|
|
p->type = SCTP_PARAM_RANDOM;
|
|
|
|
p->length = htons(sizeof(sctp_paramhdr_t) + SCTP_AUTH_RANDOM_LENGTH);
|
|
|
|
get_random_bytes(p+1, SCTP_AUTH_RANDOM_LENGTH);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return asoc;
|
|
|
|
|
|
|
|
fail_init:
|
|
|
|
sock_put(asoc->base.sk);
|
2013-06-14 16:24:07 +00:00
|
|
|
sctp_endpoint_put(asoc->ep);
|
2005-04-16 22:20:36 +00:00
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate and initialize a new association */
|
|
|
|
struct sctp_association *sctp_association_new(const struct sctp_endpoint *ep,
|
|
|
|
const struct sock *sk,
|
2005-07-12 03:57:47 +00:00
|
|
|
sctp_scope_t scope,
|
2005-10-07 06:46:04 +00:00
|
|
|
gfp_t gfp)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct sctp_association *asoc;
|
|
|
|
|
2013-06-17 09:40:04 +00:00
|
|
|
asoc = kzalloc(sizeof(*asoc), gfp);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!asoc)
|
|
|
|
goto fail;
|
|
|
|
|
|
|
|
if (!sctp_association_init(asoc, ep, sk, scope, gfp))
|
|
|
|
goto fail_init;
|
|
|
|
|
|
|
|
SCTP_DBG_OBJCNT_INC(assoc);
|
net: sctp: rework debugging framework to use pr_debug and friends
We should get rid of all own SCTP debug printk macros and use the ones
that the kernel offers anyway instead. This makes the code more readable
and conform to the kernel code, and offers all the features of dynamic
debbuging that pr_debug() et al has, such as only turning on/off portions
of debug messages at runtime through debugfs. The runtime cost of having
CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
is negligible [1]. If kernel debugging is completly turned off, then these
statements will also compile into "empty" functions.
While we're at it, we also need to change the Kconfig option as it /now/
only refers to the ifdef'ed code portions in outqueue.c that enable further
debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
was enabled with this Kconfig option and has now been removed, we
transform those code parts into WARNs resp. where appropriate BUG_ONs so
that those bugs can be more easily detected as probably not many people
have SCTP debugging permanently turned on.
To turn on all SCTP debugging, the following steps are needed:
# mount -t debugfs none /sys/kernel/debug
# echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
This can be done more fine-grained on a per file, per line basis and others
as described in [2].
[1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
[2] Documentation/dynamic-debug-howto.txt
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-28 17:49:40 +00:00
|
|
|
|
|
|
|
pr_debug("Created asoc %p\n", asoc);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return asoc;
|
|
|
|
|
|
|
|
fail_init:
|
|
|
|
kfree(asoc);
|
|
|
|
fail:
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Free this association if possible. There may still be users, so
|
|
|
|
* the actual deallocation may be delayed.
|
|
|
|
*/
|
|
|
|
void sctp_association_free(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
struct sock *sk = asoc->base.sk;
|
|
|
|
struct sctp_transport *transport;
|
|
|
|
struct list_head *pos, *temp;
|
|
|
|
int i;
|
|
|
|
|
2006-10-31 02:55:11 +00:00
|
|
|
/* Only real associations count against the endpoint, so
|
|
|
|
* don't bother for if this is a temporary association.
|
|
|
|
*/
|
sctp: Fix sk_ack_backlog wrap-around problem
Consider the scenario:
For a TCP-style socket, while processing the COOKIE_ECHO chunk in
sctp_sf_do_5_1D_ce(), after it has passed a series of sanity check,
a new association would be created in sctp_unpack_cookie(), but afterwards,
some processing maybe failed, and sctp_association_free() will be called to
free the previously allocated association, in sctp_association_free(),
sk_ack_backlog value is decremented for this socket, since the initial
value for sk_ack_backlog is 0, after the decrement, it will be 65535,
a wrap-around problem happens, and if we want to establish new associations
afterward in the same socket, ABORT would be triggered since sctp deem the
accept queue as full.
Fix this issue by only decrementing sk_ack_backlog for associations in
the endpoint's list.
Fix-suggested-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: Xufeng Zhang <xufeng.zhang@windriver.com>
Acked-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-12 02:53:36 +00:00
|
|
|
if (!list_empty(&asoc->asocs)) {
|
2006-10-31 02:55:11 +00:00
|
|
|
list_del(&asoc->asocs);
|
|
|
|
|
|
|
|
/* Decrement the backlog value for a TCP-style listening
|
|
|
|
* socket.
|
|
|
|
*/
|
|
|
|
if (sctp_style(sk, TCP) && sctp_sstate(sk, LISTENING))
|
|
|
|
sk->sk_ack_backlog--;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Mark as dead, so other users can know this structure is
|
|
|
|
* going away.
|
|
|
|
*/
|
2013-04-15 03:27:18 +00:00
|
|
|
asoc->base.dead = true;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Dispose of any data lying around in the outqueue. */
|
|
|
|
sctp_outq_free(&asoc->outqueue);
|
|
|
|
|
|
|
|
/* Dispose of any pending messages for the upper layer. */
|
|
|
|
sctp_ulpq_free(&asoc->ulpq);
|
|
|
|
|
|
|
|
/* Dispose of any pending chunks on the inqueue. */
|
|
|
|
sctp_inq_free(&asoc->base.inqueue);
|
|
|
|
|
2008-10-08 21:18:39 +00:00
|
|
|
sctp_tsnmap_free(&asoc->peer.tsn_map);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Free ssnmap storage. */
|
|
|
|
sctp_ssnmap_free(asoc->ssnmap);
|
|
|
|
|
|
|
|
/* Clean up the bound address list. */
|
|
|
|
sctp_bind_addr_free(&asoc->base.bind_addr);
|
|
|
|
|
|
|
|
/* Do we need to go through all of our timers and
|
|
|
|
* delete them? To be safe we will try to delete all, but we
|
|
|
|
* should be able to go through and make a guess based
|
|
|
|
* on our state.
|
|
|
|
*/
|
|
|
|
for (i = SCTP_EVENT_TIMEOUT_NONE; i < SCTP_NUM_TIMEOUT_TYPES; ++i) {
|
2013-02-03 20:32:57 +00:00
|
|
|
if (del_timer(&asoc->timers[i]))
|
2005-04-16 22:20:36 +00:00
|
|
|
sctp_association_put(asoc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Free peer's cached cookie. */
|
2005-11-08 17:41:34 +00:00
|
|
|
kfree(asoc->peer.cookie);
|
2007-09-17 02:32:11 +00:00
|
|
|
kfree(asoc->peer.peer_random);
|
|
|
|
kfree(asoc->peer.peer_chunks);
|
|
|
|
kfree(asoc->peer.peer_hmacs);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Release the transport structures. */
|
|
|
|
list_for_each_safe(pos, temp, &asoc->peer.transport_addr_list) {
|
|
|
|
transport = list_entry(pos, struct sctp_transport, transports);
|
2012-12-06 09:25:05 +00:00
|
|
|
list_del_rcu(pos);
|
2005-04-16 22:20:36 +00:00
|
|
|
sctp_transport_free(transport);
|
|
|
|
}
|
|
|
|
|
2005-06-20 20:14:57 +00:00
|
|
|
asoc->peer.transport_count = 0;
|
|
|
|
|
2011-05-29 23:23:36 +00:00
|
|
|
sctp_asconf_queue_teardown(asoc);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2011-04-26 11:19:36 +00:00
|
|
|
/* Free pending address space being deleted */
|
|
|
|
if (asoc->asconf_addr_del_pending != NULL)
|
|
|
|
kfree(asoc->asconf_addr_del_pending);
|
|
|
|
|
2007-09-17 02:31:35 +00:00
|
|
|
/* AUTH - Free the endpoint shared keys */
|
|
|
|
sctp_auth_destroy_keys(&asoc->endpoint_shared_keys);
|
|
|
|
|
|
|
|
/* AUTH - Free the association shared key */
|
|
|
|
sctp_auth_key_put(asoc->asoc_shared_key);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
sctp_association_put(asoc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Cleanup and free up an association. */
|
|
|
|
static void sctp_association_destroy(struct sctp_association *asoc)
|
|
|
|
{
|
net: sctp: rework debugging framework to use pr_debug and friends
We should get rid of all own SCTP debug printk macros and use the ones
that the kernel offers anyway instead. This makes the code more readable
and conform to the kernel code, and offers all the features of dynamic
debbuging that pr_debug() et al has, such as only turning on/off portions
of debug messages at runtime through debugfs. The runtime cost of having
CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
is negligible [1]. If kernel debugging is completly turned off, then these
statements will also compile into "empty" functions.
While we're at it, we also need to change the Kconfig option as it /now/
only refers to the ifdef'ed code portions in outqueue.c that enable further
debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
was enabled with this Kconfig option and has now been removed, we
transform those code parts into WARNs resp. where appropriate BUG_ONs so
that those bugs can be more easily detected as probably not many people
have SCTP debugging permanently turned on.
To turn on all SCTP debugging, the following steps are needed:
# mount -t debugfs none /sys/kernel/debug
# echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
This can be done more fine-grained on a per file, per line basis and others
as described in [2].
[1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
[2] Documentation/dynamic-debug-howto.txt
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-28 17:49:40 +00:00
|
|
|
if (unlikely(!asoc->base.dead)) {
|
|
|
|
WARN(1, "Attempt to destroy undead association %p!\n", asoc);
|
|
|
|
return;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
sctp_endpoint_put(asoc->ep);
|
|
|
|
sock_put(asoc->base.sk);
|
|
|
|
|
|
|
|
if (asoc->assoc_id != 0) {
|
|
|
|
spin_lock_bh(&sctp_assocs_id_lock);
|
|
|
|
idr_remove(&sctp_assocs_id, asoc->assoc_id);
|
|
|
|
spin_unlock_bh(&sctp_assocs_id_lock);
|
|
|
|
}
|
|
|
|
|
2008-07-26 04:43:18 +00:00
|
|
|
WARN_ON(atomic_read(&asoc->rmem_alloc));
|
2005-11-12 00:08:24 +00:00
|
|
|
|
2013-04-15 03:27:17 +00:00
|
|
|
kfree(asoc);
|
|
|
|
SCTP_DBG_OBJCNT_DEC(assoc);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Change the primary destination address for the peer. */
|
|
|
|
void sctp_assoc_set_primary(struct sctp_association *asoc,
|
|
|
|
struct sctp_transport *transport)
|
|
|
|
{
|
2008-06-17 00:00:29 +00:00
|
|
|
int changeover = 0;
|
|
|
|
|
|
|
|
/* it's a changeover only if we already have a primary path
|
|
|
|
* that we are changing
|
|
|
|
*/
|
|
|
|
if (asoc->peer.primary_path != NULL &&
|
|
|
|
asoc->peer.primary_path != transport)
|
|
|
|
changeover = 1 ;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
asoc->peer.primary_path = transport;
|
|
|
|
|
|
|
|
/* Set a default msg_name for events. */
|
|
|
|
memcpy(&asoc->peer.primary_addr, &transport->ipaddr,
|
|
|
|
sizeof(union sctp_addr));
|
|
|
|
|
|
|
|
/* If the primary path is changing, assume that the
|
|
|
|
* user wants to use this new path.
|
|
|
|
*/
|
2006-07-21 21:48:50 +00:00
|
|
|
if ((transport->state == SCTP_ACTIVE) ||
|
|
|
|
(transport->state == SCTP_UNKNOWN))
|
2005-04-16 22:20:36 +00:00
|
|
|
asoc->peer.active_path = transport;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* SFR-CACC algorithm:
|
|
|
|
* Upon the receipt of a request to change the primary
|
|
|
|
* destination address, on the data structure for the new
|
|
|
|
* primary destination, the sender MUST do the following:
|
|
|
|
*
|
|
|
|
* 1) If CHANGEOVER_ACTIVE is set, then there was a switch
|
|
|
|
* to this destination address earlier. The sender MUST set
|
|
|
|
* CYCLING_CHANGEOVER to indicate that this switch is a
|
|
|
|
* double switch to the same destination address.
|
2009-11-23 20:53:57 +00:00
|
|
|
*
|
|
|
|
* Really, only bother is we have data queued or outstanding on
|
|
|
|
* the association.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2009-11-23 20:53:57 +00:00
|
|
|
if (!asoc->outqueue.outstanding_bytes && !asoc->outqueue.out_qlen)
|
|
|
|
return;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
if (transport->cacc.changeover_active)
|
2008-06-17 00:00:29 +00:00
|
|
|
transport->cacc.cycling_changeover = changeover;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* 2) The sender MUST set CHANGEOVER_ACTIVE to indicate that
|
|
|
|
* a changeover has occurred.
|
|
|
|
*/
|
2008-06-17 00:00:29 +00:00
|
|
|
transport->cacc.changeover_active = changeover;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* 3) The sender MUST store the next TSN to be sent in
|
|
|
|
* next_tsn_at_change.
|
|
|
|
*/
|
|
|
|
transport->cacc.next_tsn_at_change = asoc->next_tsn;
|
|
|
|
}
|
|
|
|
|
2005-06-20 20:14:57 +00:00
|
|
|
/* Remove a transport from an association. */
|
|
|
|
void sctp_assoc_rm_peer(struct sctp_association *asoc,
|
|
|
|
struct sctp_transport *peer)
|
|
|
|
{
|
|
|
|
struct list_head *pos;
|
|
|
|
struct sctp_transport *transport;
|
|
|
|
|
net: sctp: rework debugging framework to use pr_debug and friends
We should get rid of all own SCTP debug printk macros and use the ones
that the kernel offers anyway instead. This makes the code more readable
and conform to the kernel code, and offers all the features of dynamic
debbuging that pr_debug() et al has, such as only turning on/off portions
of debug messages at runtime through debugfs. The runtime cost of having
CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
is negligible [1]. If kernel debugging is completly turned off, then these
statements will also compile into "empty" functions.
While we're at it, we also need to change the Kconfig option as it /now/
only refers to the ifdef'ed code portions in outqueue.c that enable further
debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
was enabled with this Kconfig option and has now been removed, we
transform those code parts into WARNs resp. where appropriate BUG_ONs so
that those bugs can be more easily detected as probably not many people
have SCTP debugging permanently turned on.
To turn on all SCTP debugging, the following steps are needed:
# mount -t debugfs none /sys/kernel/debug
# echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
This can be done more fine-grained on a per file, per line basis and others
as described in [2].
[1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
[2] Documentation/dynamic-debug-howto.txt
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-28 17:49:40 +00:00
|
|
|
pr_debug("%s: association:%p addr:%pISpc\n",
|
|
|
|
__func__, asoc, &peer->ipaddr.sa);
|
2005-06-20 20:14:57 +00:00
|
|
|
|
|
|
|
/* If we are to remove the current retran_path, update it
|
|
|
|
* to the next peer before removing this peer from the list.
|
|
|
|
*/
|
|
|
|
if (asoc->peer.retran_path == peer)
|
|
|
|
sctp_assoc_update_retran_path(asoc);
|
|
|
|
|
|
|
|
/* Remove this peer from the list. */
|
2012-12-06 09:25:05 +00:00
|
|
|
list_del_rcu(&peer->transports);
|
2005-06-20 20:14:57 +00:00
|
|
|
|
|
|
|
/* Get the first transport of asoc. */
|
|
|
|
pos = asoc->peer.transport_addr_list.next;
|
|
|
|
transport = list_entry(pos, struct sctp_transport, transports);
|
|
|
|
|
|
|
|
/* Update any entries that match the peer to be deleted. */
|
|
|
|
if (asoc->peer.primary_path == peer)
|
|
|
|
sctp_assoc_set_primary(asoc, transport);
|
|
|
|
if (asoc->peer.active_path == peer)
|
|
|
|
asoc->peer.active_path = transport;
|
2011-04-12 15:22:22 +00:00
|
|
|
if (asoc->peer.retran_path == peer)
|
|
|
|
asoc->peer.retran_path = transport;
|
2005-06-20 20:14:57 +00:00
|
|
|
if (asoc->peer.last_data_from == peer)
|
|
|
|
asoc->peer.last_data_from = transport;
|
|
|
|
|
|
|
|
/* If we remove the transport an INIT was last sent to, set it to
|
|
|
|
* NULL. Combined with the update of the retran path above, this
|
|
|
|
* will cause the next INIT to be sent to the next available
|
|
|
|
* transport, maintaining the cycle.
|
|
|
|
*/
|
|
|
|
if (asoc->init_last_sent_to == peer)
|
|
|
|
asoc->init_last_sent_to = NULL;
|
|
|
|
|
2009-04-26 15:13:35 +00:00
|
|
|
/* If we remove the transport an SHUTDOWN was last sent to, set it
|
|
|
|
* to NULL. Combined with the update of the retran path above, this
|
|
|
|
* will cause the next SHUTDOWN to be sent to the next available
|
|
|
|
* transport, maintaining the cycle.
|
|
|
|
*/
|
|
|
|
if (asoc->shutdown_last_sent_to == peer)
|
|
|
|
asoc->shutdown_last_sent_to = NULL;
|
|
|
|
|
2009-04-26 15:14:42 +00:00
|
|
|
/* If we remove the transport an ASCONF was last sent to, set it to
|
|
|
|
* NULL.
|
|
|
|
*/
|
|
|
|
if (asoc->addip_last_asconf &&
|
|
|
|
asoc->addip_last_asconf->transport == peer)
|
|
|
|
asoc->addip_last_asconf->transport = NULL;
|
|
|
|
|
2009-09-04 22:21:00 +00:00
|
|
|
/* If we have something on the transmitted list, we have to
|
|
|
|
* save it off. The best place is the active path.
|
|
|
|
*/
|
|
|
|
if (!list_empty(&peer->transmitted)) {
|
|
|
|
struct sctp_transport *active = asoc->peer.active_path;
|
|
|
|
struct sctp_chunk *ch;
|
|
|
|
|
|
|
|
/* Reset the transport of each chunk on this list */
|
|
|
|
list_for_each_entry(ch, &peer->transmitted,
|
|
|
|
transmitted_list) {
|
|
|
|
ch->transport = NULL;
|
|
|
|
ch->rtt_in_progress = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
list_splice_tail_init(&peer->transmitted,
|
|
|
|
&active->transmitted);
|
|
|
|
|
|
|
|
/* Start a T3 timer here in case it wasn't running so
|
|
|
|
* that these migrated packets have a chance to get
|
2013-10-26 08:06:30 +00:00
|
|
|
* retransmitted.
|
2009-09-04 22:21:00 +00:00
|
|
|
*/
|
|
|
|
if (!timer_pending(&active->T3_rtx_timer))
|
|
|
|
if (!mod_timer(&active->T3_rtx_timer,
|
|
|
|
jiffies + active->rto))
|
|
|
|
sctp_transport_hold(active);
|
|
|
|
}
|
|
|
|
|
2005-06-20 20:14:57 +00:00
|
|
|
asoc->peer.transport_count--;
|
|
|
|
|
|
|
|
sctp_transport_free(peer);
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Add a transport address to an association. */
|
|
|
|
struct sctp_transport *sctp_assoc_add_peer(struct sctp_association *asoc,
|
|
|
|
const union sctp_addr *addr,
|
2005-10-07 06:46:04 +00:00
|
|
|
const gfp_t gfp,
|
2005-06-20 20:14:57 +00:00
|
|
|
const int peer_state)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2012-08-07 07:26:14 +00:00
|
|
|
struct net *net = sock_net(asoc->base.sk);
|
2005-04-16 22:20:36 +00:00
|
|
|
struct sctp_transport *peer;
|
|
|
|
struct sctp_sock *sp;
|
|
|
|
unsigned short port;
|
|
|
|
|
|
|
|
sp = sctp_sk(asoc->base.sk);
|
|
|
|
|
|
|
|
/* AF_INET and AF_INET6 share common port field. */
|
2006-11-21 01:10:20 +00:00
|
|
|
port = ntohs(addr->v4.sin_port);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
net: sctp: rework debugging framework to use pr_debug and friends
We should get rid of all own SCTP debug printk macros and use the ones
that the kernel offers anyway instead. This makes the code more readable
and conform to the kernel code, and offers all the features of dynamic
debbuging that pr_debug() et al has, such as only turning on/off portions
of debug messages at runtime through debugfs. The runtime cost of having
CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
is negligible [1]. If kernel debugging is completly turned off, then these
statements will also compile into "empty" functions.
While we're at it, we also need to change the Kconfig option as it /now/
only refers to the ifdef'ed code portions in outqueue.c that enable further
debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
was enabled with this Kconfig option and has now been removed, we
transform those code parts into WARNs resp. where appropriate BUG_ONs so
that those bugs can be more easily detected as probably not many people
have SCTP debugging permanently turned on.
To turn on all SCTP debugging, the following steps are needed:
# mount -t debugfs none /sys/kernel/debug
# echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
This can be done more fine-grained on a per file, per line basis and others
as described in [2].
[1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
[2] Documentation/dynamic-debug-howto.txt
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-28 17:49:40 +00:00
|
|
|
pr_debug("%s: association:%p addr:%pISpc state:%d\n", __func__,
|
|
|
|
asoc, &addr->sa, peer_state);
|
2005-06-20 20:14:57 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Set the port if it has not been set yet. */
|
|
|
|
if (0 == asoc->peer.port)
|
|
|
|
asoc->peer.port = port;
|
|
|
|
|
|
|
|
/* Check to see if this is a duplicate. */
|
|
|
|
peer = sctp_assoc_lookup_paddr(asoc, addr);
|
2005-06-20 20:14:57 +00:00
|
|
|
if (peer) {
|
2008-09-18 23:28:27 +00:00
|
|
|
/* An UNKNOWN state is only set on transports added by
|
|
|
|
* user in sctp_connectx() call. Such transports should be
|
|
|
|
* considered CONFIRMED per RFC 4960, Section 5.4.
|
|
|
|
*/
|
2006-07-21 21:48:50 +00:00
|
|
|
if (peer->state == SCTP_UNKNOWN) {
|
2008-09-18 23:28:27 +00:00
|
|
|
peer->state = SCTP_ACTIVE;
|
2006-07-21 21:48:50 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
return peer;
|
2005-06-20 20:14:57 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2012-08-07 07:26:14 +00:00
|
|
|
peer = sctp_transport_new(net, addr, gfp);
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!peer)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
sctp_transport_set_owner(peer, asoc);
|
|
|
|
|
2005-12-22 19:36:46 +00:00
|
|
|
/* Initialize the peer's heartbeat interval based on the
|
|
|
|
* association configured value.
|
|
|
|
*/
|
|
|
|
peer->hbinterval = asoc->hbinterval;
|
|
|
|
|
|
|
|
/* Set the path max_retrans. */
|
|
|
|
peer->pathmaxrxt = asoc->pathmaxrxt;
|
|
|
|
|
2013-10-26 08:06:30 +00:00
|
|
|
/* And the partial failure retrans threshold */
|
2012-07-21 07:56:07 +00:00
|
|
|
peer->pf_retrans = asoc->pf_retrans;
|
|
|
|
|
2005-12-22 19:36:46 +00:00
|
|
|
/* Initialize the peer's SACK delay timeout based on the
|
|
|
|
* association configured value.
|
|
|
|
*/
|
|
|
|
peer->sackdelay = asoc->sackdelay;
|
2008-05-09 22:13:26 +00:00
|
|
|
peer->sackfreq = asoc->sackfreq;
|
2005-12-22 19:36:46 +00:00
|
|
|
|
|
|
|
/* Enable/disable heartbeat, SACK delay, and path MTU discovery
|
|
|
|
* based on association setting.
|
|
|
|
*/
|
|
|
|
peer->param_flags = asoc->param_flags;
|
|
|
|
|
2009-09-04 22:21:01 +00:00
|
|
|
sctp_transport_route(peer, NULL, sp);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Initialize the pmtu of the transport. */
|
2009-09-04 22:21:01 +00:00
|
|
|
if (peer->param_flags & SPP_PMTUD_DISABLE) {
|
|
|
|
if (asoc->pathmtu)
|
|
|
|
peer->pathmtu = asoc->pathmtu;
|
|
|
|
else
|
|
|
|
peer->pathmtu = SCTP_DEFAULT_MAXSEGMENT;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* If this is the first transport addr on this association,
|
|
|
|
* initialize the association PMTU to the peer's PMTU.
|
|
|
|
* If not and the current association PMTU is higher than the new
|
|
|
|
* peer's PMTU, reset the association PMTU to the new peer's PMTU.
|
|
|
|
*/
|
2005-12-22 19:36:46 +00:00
|
|
|
if (asoc->pathmtu)
|
|
|
|
asoc->pathmtu = min_t(int, peer->pathmtu, asoc->pathmtu);
|
2005-04-16 22:20:36 +00:00
|
|
|
else
|
2005-12-22 19:36:46 +00:00
|
|
|
asoc->pathmtu = peer->pathmtu;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
net: sctp: rework debugging framework to use pr_debug and friends
We should get rid of all own SCTP debug printk macros and use the ones
that the kernel offers anyway instead. This makes the code more readable
and conform to the kernel code, and offers all the features of dynamic
debbuging that pr_debug() et al has, such as only turning on/off portions
of debug messages at runtime through debugfs. The runtime cost of having
CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
is negligible [1]. If kernel debugging is completly turned off, then these
statements will also compile into "empty" functions.
While we're at it, we also need to change the Kconfig option as it /now/
only refers to the ifdef'ed code portions in outqueue.c that enable further
debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
was enabled with this Kconfig option and has now been removed, we
transform those code parts into WARNs resp. where appropriate BUG_ONs so
that those bugs can be more easily detected as probably not many people
have SCTP debugging permanently turned on.
To turn on all SCTP debugging, the following steps are needed:
# mount -t debugfs none /sys/kernel/debug
# echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
This can be done more fine-grained on a per file, per line basis and others
as described in [2].
[1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
[2] Documentation/dynamic-debug-howto.txt
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-28 17:49:40 +00:00
|
|
|
pr_debug("%s: association:%p PMTU set to %d\n", __func__, asoc,
|
|
|
|
asoc->pathmtu);
|
|
|
|
|
2008-07-19 06:04:39 +00:00
|
|
|
peer->pmtu_pending = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2009-09-04 22:21:00 +00:00
|
|
|
asoc->frag_point = sctp_frag_point(asoc, asoc->pathmtu);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* The asoc->peer.port might not be meaningful yet, but
|
|
|
|
* initialize the packet structure anyway.
|
|
|
|
*/
|
|
|
|
sctp_packet_init(&peer->packet, peer, asoc->base.bind_addr.port,
|
|
|
|
asoc->peer.port);
|
|
|
|
|
|
|
|
/* 7.2.1 Slow-Start
|
|
|
|
*
|
|
|
|
* o The initial cwnd before DATA transmission or after a sufficiently
|
|
|
|
* long idle period MUST be set to
|
|
|
|
* min(4*MTU, max(2*MTU, 4380 bytes))
|
|
|
|
*
|
|
|
|
* o The initial value of ssthresh MAY be arbitrarily high
|
|
|
|
* (for example, implementations MAY use the size of the
|
|
|
|
* receiver advertised window).
|
|
|
|
*/
|
2005-12-22 19:36:46 +00:00
|
|
|
peer->cwnd = min(4*asoc->pathmtu, max_t(__u32, 2*asoc->pathmtu, 4380));
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* At this point, we may not have the receiver's advertised window,
|
|
|
|
* so initialize ssthresh to the default value and it will be set
|
|
|
|
* later when we process the INIT.
|
|
|
|
*/
|
|
|
|
peer->ssthresh = SCTP_DEFAULT_MAXWINDOW;
|
|
|
|
|
|
|
|
peer->partial_bytes_acked = 0;
|
|
|
|
peer->flight_size = 0;
|
2009-11-23 20:54:00 +00:00
|
|
|
peer->burst_limited = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Set the transport's RTO.initial value */
|
|
|
|
peer->rto = asoc->rto_initial;
|
2012-12-01 04:49:42 +00:00
|
|
|
sctp_max_rto(asoc, peer);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2005-06-20 20:14:57 +00:00
|
|
|
/* Set the peer's active state. */
|
|
|
|
peer->state = peer_state;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Attach the remote transport to our asoc. */
|
2012-12-06 09:25:05 +00:00
|
|
|
list_add_tail_rcu(&peer->transports, &asoc->peer.transport_addr_list);
|
2005-06-20 20:14:57 +00:00
|
|
|
asoc->peer.transport_count++;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* If we do not yet have a primary path, set one. */
|
|
|
|
if (!asoc->peer.primary_path) {
|
|
|
|
sctp_assoc_set_primary(asoc, peer);
|
|
|
|
asoc->peer.retran_path = peer;
|
|
|
|
}
|
|
|
|
|
2010-05-01 02:39:26 +00:00
|
|
|
if (asoc->peer.active_path == asoc->peer.retran_path &&
|
|
|
|
peer->state != SCTP_UNCONFIRMED) {
|
2005-04-16 22:20:36 +00:00
|
|
|
asoc->peer.retran_path = peer;
|
2005-06-20 20:14:57 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
return peer;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Delete a transport address from an association. */
|
|
|
|
void sctp_assoc_del_peer(struct sctp_association *asoc,
|
|
|
|
const union sctp_addr *addr)
|
|
|
|
{
|
|
|
|
struct list_head *pos;
|
|
|
|
struct list_head *temp;
|
|
|
|
struct sctp_transport *transport;
|
|
|
|
|
|
|
|
list_for_each_safe(pos, temp, &asoc->peer.transport_addr_list) {
|
|
|
|
transport = list_entry(pos, struct sctp_transport, transports);
|
|
|
|
if (sctp_cmp_addr_exact(addr, &transport->ipaddr)) {
|
2005-06-20 20:14:57 +00:00
|
|
|
/* Do book keeping for removing the peer and free it. */
|
|
|
|
sctp_assoc_rm_peer(asoc, transport);
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Lookup a transport by address. */
|
|
|
|
struct sctp_transport *sctp_assoc_lookup_paddr(
|
|
|
|
const struct sctp_association *asoc,
|
|
|
|
const union sctp_addr *address)
|
|
|
|
{
|
|
|
|
struct sctp_transport *t;
|
|
|
|
|
|
|
|
/* Cycle through all transports searching for a peer address. */
|
|
|
|
|
2008-04-13 01:54:24 +00:00
|
|
|
list_for_each_entry(t, &asoc->peer.transport_addr_list,
|
|
|
|
transports) {
|
2005-04-16 22:20:36 +00:00
|
|
|
if (sctp_cmp_addr_exact(address, &t->ipaddr))
|
|
|
|
return t;
|
|
|
|
}
|
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2007-12-20 22:08:56 +00:00
|
|
|
/* Remove all transports except a give one */
|
|
|
|
void sctp_assoc_del_nonprimary_peers(struct sctp_association *asoc,
|
|
|
|
struct sctp_transport *primary)
|
|
|
|
{
|
|
|
|
struct sctp_transport *temp;
|
|
|
|
struct sctp_transport *t;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(t, temp, &asoc->peer.transport_addr_list,
|
|
|
|
transports) {
|
|
|
|
/* if the current transport is not the primary one, delete it */
|
|
|
|
if (t != primary)
|
|
|
|
sctp_assoc_rm_peer(asoc, t);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Engage in transport control operations.
|
|
|
|
* Mark the transport up or down and send a notification to the user.
|
|
|
|
* Select and update the new active and retran paths.
|
|
|
|
*/
|
|
|
|
void sctp_assoc_control_transport(struct sctp_association *asoc,
|
|
|
|
struct sctp_transport *transport,
|
|
|
|
sctp_transport_cmd_t command,
|
|
|
|
sctp_sn_error_t error)
|
|
|
|
{
|
|
|
|
struct sctp_ulpevent *event;
|
2006-11-21 01:03:01 +00:00
|
|
|
struct sockaddr_storage addr;
|
2005-04-16 22:20:36 +00:00
|
|
|
int spc_state = 0;
|
2012-07-21 07:56:07 +00:00
|
|
|
bool ulp_notify = true;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Record the transition on the transport. */
|
|
|
|
switch (command) {
|
|
|
|
case SCTP_TRANSPORT_UP:
|
2007-03-23 18:32:26 +00:00
|
|
|
/* If we are moving from UNCONFIRMED state due
|
|
|
|
* to heartbeat success, report the SCTP_ADDR_CONFIRMED
|
|
|
|
* state to the user, otherwise report SCTP_ADDR_AVAILABLE.
|
|
|
|
*/
|
|
|
|
if (SCTP_UNCONFIRMED == transport->state &&
|
|
|
|
SCTP_HEARTBEAT_SUCCESS == error)
|
|
|
|
spc_state = SCTP_ADDR_CONFIRMED;
|
|
|
|
else
|
|
|
|
spc_state = SCTP_ADDR_AVAILABLE;
|
2012-07-21 07:56:07 +00:00
|
|
|
/* Don't inform ULP about transition from PF to
|
2013-08-09 13:09:08 +00:00
|
|
|
* active state and set cwnd to 1 MTU, see SCTP
|
2012-07-21 07:56:07 +00:00
|
|
|
* Quick failover draft section 5.1, point 5
|
|
|
|
*/
|
|
|
|
if (transport->state == SCTP_PF) {
|
|
|
|
ulp_notify = false;
|
2013-08-09 13:09:08 +00:00
|
|
|
transport->cwnd = asoc->pathmtu;
|
2012-07-21 07:56:07 +00:00
|
|
|
}
|
2005-06-20 20:14:57 +00:00
|
|
|
transport->state = SCTP_ACTIVE;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case SCTP_TRANSPORT_DOWN:
|
2009-06-23 15:28:05 +00:00
|
|
|
/* If the transport was never confirmed, do not transition it
|
|
|
|
* to inactive state. Also, release the cached route since
|
|
|
|
* there may be a better route next time.
|
2007-08-24 10:30:25 +00:00
|
|
|
*/
|
|
|
|
if (transport->state != SCTP_UNCONFIRMED)
|
|
|
|
transport->state = SCTP_INACTIVE;
|
2009-06-23 15:28:05 +00:00
|
|
|
else {
|
|
|
|
dst_release(transport->dst);
|
|
|
|
transport->dst = NULL;
|
|
|
|
}
|
2007-08-24 10:30:25 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
spc_state = SCTP_ADDR_UNREACHABLE;
|
|
|
|
break;
|
|
|
|
|
2012-07-21 07:56:07 +00:00
|
|
|
case SCTP_TRANSPORT_PF:
|
|
|
|
transport->state = SCTP_PF;
|
|
|
|
ulp_notify = false;
|
|
|
|
break;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
default:
|
|
|
|
return;
|
2007-04-21 00:09:22 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
2014-06-11 16:19:29 +00:00
|
|
|
/* Generate and send a SCTP_PEER_ADDR_CHANGE notification
|
|
|
|
* to the user.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
2012-07-21 07:56:07 +00:00
|
|
|
if (ulp_notify) {
|
|
|
|
memset(&addr, 0, sizeof(struct sockaddr_storage));
|
|
|
|
memcpy(&addr, &transport->ipaddr,
|
|
|
|
transport->af_specific->sockaddr_len);
|
2014-06-11 16:19:29 +00:00
|
|
|
|
2012-07-21 07:56:07 +00:00
|
|
|
event = sctp_ulpevent_make_peer_addr_change(asoc, &addr,
|
|
|
|
0, spc_state, error, GFP_ATOMIC);
|
|
|
|
if (event)
|
|
|
|
sctp_ulpq_tail_event(&asoc->ulpq, event);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Select new active and retran paths. */
|
2014-06-11 16:19:29 +00:00
|
|
|
sctp_select_active_and_retran_path(asoc);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Hold a reference to an association. */
|
|
|
|
void sctp_association_hold(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
atomic_inc(&asoc->base.refcnt);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Release a reference to an association and cleanup
|
|
|
|
* if there are no more references.
|
|
|
|
*/
|
|
|
|
void sctp_association_put(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
if (atomic_dec_and_test(&asoc->base.refcnt))
|
|
|
|
sctp_association_destroy(asoc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Allocate the next TSN, Transmission Sequence Number, for the given
|
|
|
|
* association.
|
|
|
|
*/
|
|
|
|
__u32 sctp_association_get_next_tsn(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
/* From Section 1.6 Serial Number Arithmetic:
|
|
|
|
* Transmission Sequence Numbers wrap around when they reach
|
|
|
|
* 2**32 - 1. That is, the next TSN a DATA chunk MUST use
|
|
|
|
* after transmitting TSN = 2*32 - 1 is TSN = 0.
|
|
|
|
*/
|
|
|
|
__u32 retval = asoc->next_tsn;
|
|
|
|
asoc->next_tsn++;
|
|
|
|
asoc->unack_data++;
|
|
|
|
|
|
|
|
return retval;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Compare two addresses to see if they match. Wildcard addresses
|
|
|
|
* only match themselves.
|
|
|
|
*/
|
|
|
|
int sctp_cmp_addr_exact(const union sctp_addr *ss1,
|
|
|
|
const union sctp_addr *ss2)
|
|
|
|
{
|
|
|
|
struct sctp_af *af;
|
|
|
|
|
|
|
|
af = sctp_get_af_specific(ss1->sa.sa_family);
|
|
|
|
if (unlikely(!af))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
return af->cmp_addr(ss1, ss2);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Return an ecne chunk to get prepended to a packet.
|
|
|
|
* Note: We are sly and return a shared, prealloced chunk. FIXME:
|
|
|
|
* No we don't, but we could/should.
|
|
|
|
*/
|
|
|
|
struct sctp_chunk *sctp_get_ecne_prepend(struct sctp_association *asoc)
|
|
|
|
{
|
2013-12-06 01:36:28 +00:00
|
|
|
if (!asoc->need_ecne)
|
|
|
|
return NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Send ECNE if needed.
|
|
|
|
* Not being able to allocate a chunk here is not deadly.
|
|
|
|
*/
|
2013-12-06 01:36:28 +00:00
|
|
|
return sctp_make_ecne(asoc, asoc->last_ecne_tsn);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Find which transport this TSN was sent on.
|
|
|
|
*/
|
|
|
|
struct sctp_transport *sctp_assoc_lookup_tsn(struct sctp_association *asoc,
|
|
|
|
__u32 tsn)
|
|
|
|
{
|
|
|
|
struct sctp_transport *active;
|
|
|
|
struct sctp_transport *match;
|
|
|
|
struct sctp_transport *transport;
|
|
|
|
struct sctp_chunk *chunk;
|
2006-11-21 01:01:42 +00:00
|
|
|
__be32 key = htonl(tsn);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
match = NULL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* FIXME: In general, find a more efficient data structure for
|
|
|
|
* searching.
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* The general strategy is to search each transport's transmitted
|
|
|
|
* list. Return which transport this TSN lives on.
|
|
|
|
*
|
|
|
|
* Let's be hopeful and check the active_path first.
|
|
|
|
* Another optimization would be to know if there is only one
|
|
|
|
* outbound path and not have to look for the TSN at all.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
active = asoc->peer.active_path;
|
|
|
|
|
2008-04-13 01:54:24 +00:00
|
|
|
list_for_each_entry(chunk, &active->transmitted,
|
|
|
|
transmitted_list) {
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (key == chunk->subh.data_hdr->tsn) {
|
|
|
|
match = active;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* If not found, go search all the other transports. */
|
2008-04-13 01:54:24 +00:00
|
|
|
list_for_each_entry(transport, &asoc->peer.transport_addr_list,
|
|
|
|
transports) {
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (transport == active)
|
2013-03-07 21:39:37 +00:00
|
|
|
continue;
|
2008-04-13 01:54:24 +00:00
|
|
|
list_for_each_entry(chunk, &transport->transmitted,
|
|
|
|
transmitted_list) {
|
2005-04-16 22:20:36 +00:00
|
|
|
if (key == chunk->subh.data_hdr->tsn) {
|
|
|
|
match = transport;
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
|
|
|
out:
|
|
|
|
return match;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Is this the association we are looking for? */
|
|
|
|
struct sctp_transport *sctp_assoc_is_match(struct sctp_association *asoc,
|
2012-08-06 08:41:13 +00:00
|
|
|
struct net *net,
|
2005-04-16 22:20:36 +00:00
|
|
|
const union sctp_addr *laddr,
|
|
|
|
const union sctp_addr *paddr)
|
|
|
|
{
|
|
|
|
struct sctp_transport *transport;
|
|
|
|
|
2006-11-21 01:08:41 +00:00
|
|
|
if ((htons(asoc->base.bind_addr.port) == laddr->v4.sin_port) &&
|
2012-08-06 08:41:13 +00:00
|
|
|
(htons(asoc->peer.port) == paddr->v4.sin_port) &&
|
|
|
|
net_eq(sock_net(asoc->base.sk), net)) {
|
2005-04-16 22:20:36 +00:00
|
|
|
transport = sctp_assoc_lookup_paddr(asoc, paddr);
|
|
|
|
if (!transport)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (sctp_bind_addr_match(&asoc->base.bind_addr, laddr,
|
|
|
|
sctp_sk(asoc->base.sk)))
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
transport = NULL;
|
|
|
|
|
|
|
|
out:
|
|
|
|
return transport;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Do delayed input processing. This is scheduled by sctp_rcv(). */
|
2006-11-22 14:57:56 +00:00
|
|
|
static void sctp_assoc_bh_rcv(struct work_struct *work)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2006-11-22 14:57:56 +00:00
|
|
|
struct sctp_association *asoc =
|
|
|
|
container_of(work, struct sctp_association,
|
|
|
|
base.inqueue.immediate);
|
2012-08-07 07:25:24 +00:00
|
|
|
struct net *net = sock_net(asoc->base.sk);
|
2005-04-16 22:20:36 +00:00
|
|
|
struct sctp_endpoint *ep;
|
|
|
|
struct sctp_chunk *chunk;
|
|
|
|
struct sctp_inq *inqueue;
|
|
|
|
int state;
|
|
|
|
sctp_subtype_t subtype;
|
|
|
|
int error = 0;
|
|
|
|
|
|
|
|
/* The association should be held so we should be safe. */
|
|
|
|
ep = asoc->ep;
|
|
|
|
|
|
|
|
inqueue = &asoc->base.inqueue;
|
|
|
|
sctp_association_hold(asoc);
|
|
|
|
while (NULL != (chunk = sctp_inq_pop(inqueue))) {
|
|
|
|
state = asoc->state;
|
|
|
|
subtype = SCTP_ST_CHUNK(chunk->chunk_hdr->type);
|
|
|
|
|
2007-10-04 00:51:34 +00:00
|
|
|
/* SCTP-AUTH, Section 6.3:
|
|
|
|
* The receiver has a list of chunk types which it expects
|
|
|
|
* to be received only after an AUTH-chunk. This list has
|
|
|
|
* been sent to the peer during the association setup. It
|
|
|
|
* MUST silently discard these chunks if they are not placed
|
|
|
|
* after an AUTH chunk in the packet.
|
|
|
|
*/
|
|
|
|
if (sctp_auth_recv_cid(subtype.chunk, asoc) && !chunk->auth)
|
|
|
|
continue;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
/* Remember where the last DATA chunk came from so we
|
|
|
|
* know where to send the SACK.
|
|
|
|
*/
|
|
|
|
if (sctp_chunk_is_data(chunk))
|
|
|
|
asoc->peer.last_data_from = chunk->transport;
|
2012-12-01 04:49:42 +00:00
|
|
|
else {
|
2012-08-07 07:25:24 +00:00
|
|
|
SCTP_INC_STATS(net, SCTP_MIB_INCTRLCHUNKS);
|
2012-12-01 04:49:42 +00:00
|
|
|
asoc->stats.ictrlchunks++;
|
|
|
|
if (chunk->chunk_hdr->type == SCTP_CID_SACK)
|
|
|
|
asoc->stats.isacks++;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if (chunk->transport)
|
2014-06-11 16:19:30 +00:00
|
|
|
chunk->transport->last_time_heard = ktime_get();
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Run through the state machine. */
|
2012-08-07 07:25:24 +00:00
|
|
|
error = sctp_do_sm(net, SCTP_EVENT_T_CHUNK, subtype,
|
2005-04-16 22:20:36 +00:00
|
|
|
state, ep, asoc, chunk, GFP_ATOMIC);
|
|
|
|
|
|
|
|
/* Check to see if the association is freed in response to
|
|
|
|
* the incoming chunk. If so, get out of the while loop.
|
|
|
|
*/
|
|
|
|
if (asoc->base.dead)
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* If there is an error on chunk, discard this packet. */
|
|
|
|
if (error && chunk)
|
|
|
|
chunk->pdiscard = 1;
|
|
|
|
}
|
|
|
|
sctp_association_put(asoc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* This routine moves an association from its old sk to a new sk. */
|
|
|
|
void sctp_assoc_migrate(struct sctp_association *assoc, struct sock *newsk)
|
|
|
|
{
|
|
|
|
struct sctp_sock *newsp = sctp_sk(newsk);
|
|
|
|
struct sock *oldsk = assoc->base.sk;
|
|
|
|
|
|
|
|
/* Delete the association from the old endpoint's list of
|
|
|
|
* associations.
|
|
|
|
*/
|
|
|
|
list_del_init(&assoc->asocs);
|
|
|
|
|
|
|
|
/* Decrement the backlog value for a TCP-style socket. */
|
|
|
|
if (sctp_style(oldsk, TCP))
|
|
|
|
oldsk->sk_ack_backlog--;
|
|
|
|
|
|
|
|
/* Release references to the old endpoint and the sock. */
|
|
|
|
sctp_endpoint_put(assoc->ep);
|
|
|
|
sock_put(assoc->base.sk);
|
|
|
|
|
|
|
|
/* Get a reference to the new endpoint. */
|
|
|
|
assoc->ep = newsp->ep;
|
|
|
|
sctp_endpoint_hold(assoc->ep);
|
|
|
|
|
|
|
|
/* Get a reference to the new sock. */
|
|
|
|
assoc->base.sk = newsk;
|
|
|
|
sock_hold(assoc->base.sk);
|
|
|
|
|
|
|
|
/* Add the association to the new endpoint's list of associations. */
|
|
|
|
sctp_endpoint_add_asoc(newsp->ep, assoc);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Update an association (possibly from unexpected COOKIE-ECHO processing). */
|
|
|
|
void sctp_assoc_update(struct sctp_association *asoc,
|
|
|
|
struct sctp_association *new)
|
|
|
|
{
|
|
|
|
struct sctp_transport *trans;
|
|
|
|
struct list_head *pos, *temp;
|
|
|
|
|
|
|
|
/* Copy in new parameters of peer. */
|
|
|
|
asoc->c = new->c;
|
|
|
|
asoc->peer.rwnd = new->peer.rwnd;
|
|
|
|
asoc->peer.sack_needed = new->peer.sack_needed;
|
|
|
|
asoc->peer.i = new->peer.i;
|
2008-10-08 21:18:39 +00:00
|
|
|
sctp_tsnmap_init(&asoc->peer.tsn_map, SCTP_TSN_MAP_INITIAL,
|
|
|
|
asoc->peer.i.initial_tsn, GFP_ATOMIC);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Remove any peer addresses not present in the new association. */
|
|
|
|
list_for_each_safe(pos, temp, &asoc->peer.transport_addr_list) {
|
|
|
|
trans = list_entry(pos, struct sctp_transport, transports);
|
2010-04-28 08:47:19 +00:00
|
|
|
if (!sctp_assoc_lookup_paddr(new, &trans->ipaddr)) {
|
|
|
|
sctp_assoc_rm_peer(asoc, trans);
|
|
|
|
continue;
|
|
|
|
}
|
2007-03-20 00:02:30 +00:00
|
|
|
|
|
|
|
if (asoc->state >= SCTP_STATE_ESTABLISHED)
|
|
|
|
sctp_transport_reset(trans);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* If the case is A (association restart), use
|
|
|
|
* initial_tsn as next_tsn. If the case is B, use
|
|
|
|
* current next_tsn in case data sent to peer
|
|
|
|
* has been discarded and needs retransmission.
|
|
|
|
*/
|
|
|
|
if (asoc->state >= SCTP_STATE_ESTABLISHED) {
|
|
|
|
asoc->next_tsn = new->next_tsn;
|
|
|
|
asoc->ctsn_ack_point = new->ctsn_ack_point;
|
|
|
|
asoc->adv_peer_ack_point = new->adv_peer_ack_point;
|
|
|
|
|
|
|
|
/* Reinitialize SSN for both local streams
|
|
|
|
* and peer's streams.
|
|
|
|
*/
|
|
|
|
sctp_ssnmap_clear(asoc->ssnmap);
|
|
|
|
|
2007-03-20 00:01:17 +00:00
|
|
|
/* Flush the ULP reassembly and ordered queue.
|
|
|
|
* Any data there will now be stale and will
|
|
|
|
* cause problems.
|
|
|
|
*/
|
|
|
|
sctp_ulpq_flush(&asoc->ulpq);
|
|
|
|
|
2007-03-20 00:02:30 +00:00
|
|
|
/* reset the overall association error count so
|
|
|
|
* that the restarted association doesn't get torn
|
|
|
|
* down on the next retransmission timer.
|
|
|
|
*/
|
|
|
|
asoc->overall_error_count = 0;
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
} else {
|
|
|
|
/* Add any peer addresses from the new association. */
|
2008-04-13 01:54:24 +00:00
|
|
|
list_for_each_entry(trans, &new->peer.transport_addr_list,
|
|
|
|
transports) {
|
2005-04-16 22:20:36 +00:00
|
|
|
if (!sctp_assoc_lookup_paddr(asoc, &trans->ipaddr))
|
|
|
|
sctp_assoc_add_peer(asoc, &trans->ipaddr,
|
2006-07-21 21:48:50 +00:00
|
|
|
GFP_ATOMIC, trans->state);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
asoc->ctsn_ack_point = asoc->next_tsn - 1;
|
|
|
|
asoc->adv_peer_ack_point = asoc->ctsn_ack_point;
|
|
|
|
if (!asoc->ssnmap) {
|
|
|
|
/* Move the ssnmap. */
|
|
|
|
asoc->ssnmap = new->ssnmap;
|
|
|
|
new->ssnmap = NULL;
|
|
|
|
}
|
2007-05-04 20:55:27 +00:00
|
|
|
|
|
|
|
if (!asoc->assoc_id) {
|
|
|
|
/* get a new association id since we don't have one
|
|
|
|
* yet.
|
|
|
|
*/
|
|
|
|
sctp_assoc_set_id(asoc, GFP_ATOMIC);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
2007-09-17 02:31:35 +00:00
|
|
|
|
2013-12-06 01:36:30 +00:00
|
|
|
/* SCTP-AUTH: Save the peer parameters from the new associations
|
2007-09-17 02:32:11 +00:00
|
|
|
* and also move the association shared keys over
|
|
|
|
*/
|
|
|
|
kfree(asoc->peer.peer_random);
|
|
|
|
asoc->peer.peer_random = new->peer.peer_random;
|
|
|
|
new->peer.peer_random = NULL;
|
|
|
|
|
|
|
|
kfree(asoc->peer.peer_chunks);
|
|
|
|
asoc->peer.peer_chunks = new->peer.peer_chunks;
|
|
|
|
new->peer.peer_chunks = NULL;
|
|
|
|
|
|
|
|
kfree(asoc->peer.peer_hmacs);
|
|
|
|
asoc->peer.peer_hmacs = new->peer.peer_hmacs;
|
|
|
|
new->peer.peer_hmacs = NULL;
|
|
|
|
|
|
|
|
sctp_auth_key_put(asoc->asoc_shared_key);
|
|
|
|
sctp_auth_asoc_init_active_key(asoc, GFP_ATOMIC);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Update the retran path for sending a retransmitted packet.
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
* See also RFC4960, 6.4. Multi-Homed SCTP Endpoints:
|
|
|
|
*
|
|
|
|
* When there is outbound data to send and the primary path
|
|
|
|
* becomes inactive (e.g., due to failures), or where the
|
|
|
|
* SCTP user explicitly requests to send data to an
|
|
|
|
* inactive destination transport address, before reporting
|
|
|
|
* an error to its ULP, the SCTP endpoint should try to send
|
|
|
|
* the data to an alternate active destination transport
|
|
|
|
* address if one exists.
|
|
|
|
*
|
|
|
|
* When retransmitting data that timed out, if the endpoint
|
|
|
|
* is multihomed, it should consider each source-destination
|
|
|
|
* address pair in its retransmission selection policy.
|
|
|
|
* When retransmitting timed-out data, the endpoint should
|
|
|
|
* attempt to pick the most divergent source-destination
|
|
|
|
* pair from the original source-destination pair to which
|
|
|
|
* the packet was transmitted.
|
|
|
|
*
|
|
|
|
* Note: Rules for picking the most divergent source-destination
|
|
|
|
* pair are an implementation decision and are not specified
|
|
|
|
* within this document.
|
|
|
|
*
|
|
|
|
* Our basic strategy is to round-robin transports in priorities
|
|
|
|
* according to sctp_state_prio_map[] e.g., if no such
|
|
|
|
* transport with state SCTP_ACTIVE exists, round-robin through
|
|
|
|
* SCTP_UNKNOWN, etc. You get the picture.
|
2005-04-16 22:20:36 +00:00
|
|
|
*/
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
static const u8 sctp_trans_state_to_prio_map[] = {
|
|
|
|
[SCTP_ACTIVE] = 3, /* best case */
|
|
|
|
[SCTP_UNKNOWN] = 2,
|
|
|
|
[SCTP_PF] = 1,
|
|
|
|
[SCTP_INACTIVE] = 0, /* worst case */
|
|
|
|
};
|
|
|
|
|
|
|
|
static u8 sctp_trans_score(const struct sctp_transport *trans)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
return sctp_trans_state_to_prio_map[trans->state];
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
static struct sctp_transport *sctp_trans_elect_tie(struct sctp_transport *trans1,
|
|
|
|
struct sctp_transport *trans2)
|
|
|
|
{
|
|
|
|
if (trans1->error_count > trans2->error_count) {
|
|
|
|
return trans2;
|
|
|
|
} else if (trans1->error_count == trans2->error_count &&
|
|
|
|
ktime_after(trans2->last_time_heard,
|
|
|
|
trans1->last_time_heard)) {
|
|
|
|
return trans2;
|
|
|
|
} else {
|
|
|
|
return trans1;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
static struct sctp_transport *sctp_trans_elect_best(struct sctp_transport *curr,
|
|
|
|
struct sctp_transport *best)
|
|
|
|
{
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
u8 score_curr, score_best;
|
|
|
|
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
if (best == NULL)
|
|
|
|
return curr;
|
2008-06-04 19:37:33 +00:00
|
|
|
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
score_curr = sctp_trans_score(curr);
|
|
|
|
score_best = sctp_trans_score(best);
|
|
|
|
|
|
|
|
/* First, try a score-based selection if both transport states
|
|
|
|
* differ. If we're in a tie, lets try to make a more clever
|
|
|
|
* decision here based on error counts and last time heard.
|
|
|
|
*/
|
|
|
|
if (score_curr > score_best)
|
|
|
|
return curr;
|
|
|
|
else if (score_curr == score_best)
|
|
|
|
return sctp_trans_elect_tie(curr, best);
|
|
|
|
else
|
|
|
|
return best;
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
void sctp_assoc_update_retran_path(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
struct sctp_transport *trans = asoc->peer.retran_path;
|
|
|
|
struct sctp_transport *trans_next = NULL;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
/* We're done as we only have the one and only path. */
|
|
|
|
if (asoc->peer.transport_count == 1)
|
|
|
|
return;
|
|
|
|
/* If active_path and retran_path are the same and active,
|
|
|
|
* then this is the only active path. Use it.
|
|
|
|
*/
|
|
|
|
if (asoc->peer.active_path == asoc->peer.retran_path &&
|
|
|
|
asoc->peer.active_path->state == SCTP_ACTIVE)
|
|
|
|
return;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
/* Iterate from retran_path's successor back to retran_path. */
|
|
|
|
for (trans = list_next_entry(trans, transports); 1;
|
|
|
|
trans = list_next_entry(trans, transports)) {
|
|
|
|
/* Manually skip the head element. */
|
|
|
|
if (&trans->transports == &asoc->peer.transport_addr_list)
|
|
|
|
continue;
|
|
|
|
if (trans->state == SCTP_UNCONFIRMED)
|
|
|
|
continue;
|
|
|
|
trans_next = sctp_trans_elect_best(trans, trans_next);
|
|
|
|
/* Active is good enough for immediate return. */
|
|
|
|
if (trans_next->state == SCTP_ACTIVE)
|
2008-06-04 19:37:33 +00:00
|
|
|
break;
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
/* We've reached the end, time to update path. */
|
|
|
|
if (trans == asoc->peer.retran_path)
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
net: sctp: remove NULL check in sctp_assoc_update_retran_path
This is basically just to let Coverity et al shut up. Remove an
unneeded NULL check in sctp_assoc_update_retran_path().
It is safe to remove it, because in sctp_assoc_update_retran_path()
we iterate over the list of transports, our own transport which is
asoc->peer.retran_path included. In the iteration, we skip the
list head element and transports in state SCTP_UNCONFIRMED.
Such transports came from peer addresses received in INIT/INIT-ACK
address parameters. They are not yet confirmed by a heartbeat and
not available for data transfers.
We know however that in the list of transports, even if it contains
such elements, it at least contains our asoc->peer.retran_path as
well, so even if next to that element, we only encounter
SCTP_UNCONFIRMED transports, we are always going to fall back to
asoc->peer.retran_path through sctp_trans_elect_best(), as that is
for sure not SCTP_UNCONFIRMED as per fbdf501c9374 ("sctp: Do no
select unconfirmed transports for retransmissions").
Whenever we call sctp_trans_elect_best() it will give us a non-NULL
element back, and therefore when we break out of the loop, we are
guaranteed to have a non-NULL transport pointer, and can remove
the NULL check.
Reported-by: Dan Carpenter <dan.carpenter@oracle.com>
Reported-by: Dave Jones <davej@redhat.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-03-13 13:45:26 +00:00
|
|
|
asoc->peer.retran_path = trans_next;
|
2005-06-20 20:14:57 +00:00
|
|
|
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
pr_debug("%s: association:%p updated new path to addr:%pISpc\n",
|
|
|
|
__func__, asoc, &asoc->peer.retran_path->ipaddr.sa);
|
2005-06-20 20:14:57 +00:00
|
|
|
}
|
|
|
|
|
2014-06-11 16:19:29 +00:00
|
|
|
static void sctp_select_active_and_retran_path(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
struct sctp_transport *trans, *trans_pri = NULL, *trans_sec = NULL;
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
struct sctp_transport *trans_pf = NULL;
|
2014-06-11 16:19:29 +00:00
|
|
|
|
|
|
|
/* Look for the two most recently used active transports. */
|
|
|
|
list_for_each_entry(trans, &asoc->peer.transport_addr_list,
|
|
|
|
transports) {
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
/* Skip uninteresting transports. */
|
2014-06-11 16:19:29 +00:00
|
|
|
if (trans->state == SCTP_INACTIVE ||
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
trans->state == SCTP_UNCONFIRMED)
|
2014-06-11 16:19:29 +00:00
|
|
|
continue;
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
/* Keep track of the best PF transport from our
|
|
|
|
* list in case we don't find an active one.
|
|
|
|
*/
|
|
|
|
if (trans->state == SCTP_PF) {
|
|
|
|
trans_pf = sctp_trans_elect_best(trans, trans_pf);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
/* For active transports, pick the most recent ones. */
|
2014-06-11 16:19:29 +00:00
|
|
|
if (trans_pri == NULL ||
|
2014-06-11 16:19:30 +00:00
|
|
|
ktime_after(trans->last_time_heard,
|
|
|
|
trans_pri->last_time_heard)) {
|
2014-06-11 16:19:29 +00:00
|
|
|
trans_sec = trans_pri;
|
|
|
|
trans_pri = trans;
|
|
|
|
} else if (trans_sec == NULL ||
|
2014-06-11 16:19:30 +00:00
|
|
|
ktime_after(trans->last_time_heard,
|
|
|
|
trans_sec->last_time_heard)) {
|
2014-06-11 16:19:29 +00:00
|
|
|
trans_sec = trans;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* RFC 2960 6.4 Multi-Homed SCTP Endpoints
|
|
|
|
*
|
|
|
|
* By default, an endpoint should always transmit to the primary
|
|
|
|
* path, unless the SCTP user explicitly specifies the
|
|
|
|
* destination transport address (and possibly source transport
|
|
|
|
* address) to use. [If the primary is active but not most recent,
|
|
|
|
* bump the most recently used transport.]
|
|
|
|
*/
|
|
|
|
if ((asoc->peer.primary_path->state == SCTP_ACTIVE ||
|
|
|
|
asoc->peer.primary_path->state == SCTP_UNKNOWN) &&
|
|
|
|
asoc->peer.primary_path != trans_pri) {
|
|
|
|
trans_sec = trans_pri;
|
|
|
|
trans_pri = asoc->peer.primary_path;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* We did not find anything useful for a possible retransmission
|
|
|
|
* path; either primary path that we found is the the same as
|
|
|
|
* the current one, or we didn't generally find an active one.
|
|
|
|
*/
|
|
|
|
if (trans_sec == NULL)
|
|
|
|
trans_sec = trans_pri;
|
|
|
|
|
|
|
|
/* If we failed to find a usable transport, just camp on the
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
* primary or retran, even if they are inactive, if possible
|
|
|
|
* pick a PF iff it's the better choice.
|
2014-06-11 16:19:29 +00:00
|
|
|
*/
|
|
|
|
if (trans_pri == NULL) {
|
net: sctp: improve sctp_select_active_and_retran_path selection
In function sctp_select_active_and_retran_path(), we walk the
transport list in order to look for the two most recently used
ACTIVE transports (trans_pri, trans_sec). In case we didn't find
anything ACTIVE, we currently just camp on a possibly PF or
INACTIVE transport that is primary path; this behavior actually
dates back to linux-history tree of the very early days of
lksctp, and can yield a behavior that chooses suboptimal
transport paths.
Instead, be a bit more clever by reusing and extending the
recently introduced sctp_trans_elect_best() handler. In case
both transports are evaluated to have the same score resulting
from their states, break the tie by looking at: 1) transport
patch error count 2) last_time_heard value from each transport.
This is analogous to Nishida's Quick Failover draft [1],
section 5.1, 3:
The sender SHOULD avoid data transmission to PF destinations.
When all destinations are in either PF or Inactive state,
the sender MAY either move the destination from PF to active
state (and transmit data to the active destination) or the
sender MAY transmit data to a PF destination. In the former
scenario, (i) the sender MUST NOT notify the ULP about the
state transition, and (ii) MUST NOT clear the destination's
error counter. It is recommended that the sender picks the
PF destination with least error count (fewest consecutive
timeouts) for data transmission. In case of a tie (multiple PF
destinations with same error count), the sender MAY choose the
last active destination.
Thus for sctp_select_active_and_retran_path(), we keep track of
the best, if any, transport that is in PF state and in case no
ACTIVE transport has been found (hence trans_{pri,sec} is NULL),
we select the best out of the three: current primary_path and
retran_path as well as a possible PF transport.
The secondary may still camp on the original primary_path as
before. The change in sctp_trans_elect_best() with a more fine
grained tie selection also improves at the same time path selection
for sctp_assoc_update_retran_path() in case of non-ACTIVE states.
[1] http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-06-11 16:19:31 +00:00
|
|
|
trans_pri = sctp_trans_elect_best(asoc->peer.primary_path,
|
|
|
|
asoc->peer.retran_path);
|
|
|
|
trans_pri = sctp_trans_elect_best(trans_pri, trans_pf);
|
2014-06-11 16:19:29 +00:00
|
|
|
trans_sec = asoc->peer.primary_path;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Set the active and retran transports. */
|
|
|
|
asoc->peer.active_path = trans_pri;
|
|
|
|
asoc->peer.retran_path = trans_sec;
|
|
|
|
}
|
|
|
|
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
struct sctp_transport *
|
|
|
|
sctp_assoc_choose_alter_transport(struct sctp_association *asoc,
|
|
|
|
struct sctp_transport *last_sent_to)
|
2005-06-20 20:14:57 +00:00
|
|
|
{
|
2009-05-12 13:52:51 +00:00
|
|
|
/* If this is the first time packet is sent, use the active path,
|
|
|
|
* else use the retran path. If the last packet was sent over the
|
2005-06-20 20:14:57 +00:00
|
|
|
* retran path, update the retran path and use it.
|
|
|
|
*/
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
if (last_sent_to == NULL) {
|
2005-04-16 22:20:36 +00:00
|
|
|
return asoc->peer.active_path;
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
} else {
|
2009-05-12 13:52:51 +00:00
|
|
|
if (last_sent_to == asoc->peer.retran_path)
|
2005-04-16 22:20:36 +00:00
|
|
|
sctp_assoc_update_retran_path(asoc);
|
net: sctp: rework multihoming retransmission path selection to rfc4960
Problem statement: 1) both paths (primary path1 and alternate
path2) are up after the association has been established i.e.,
HB packets are normally exchanged, 2) path2 gets inactive after
path_max_retrans * max_rto timed out (i.e. path2 is down completely),
3) now, if a transmission times out on the only surviving/active
path1 (any ~1sec network service impact could cause this like
a channel bonding failover), then the retransmitted packets are
sent over the inactive path2; this happens with partial failover
and without it.
Besides not being optimal in the above scenario, a small failure
or timeout in the only existing path has the potential to cause
long delays in the retransmission (depending on RTO_MAX) until
the still active path is reselected. Further, when the T3-timeout
occurs, we have active_patch == retrans_path, and even though the
timeout occurred on the initial transmission of data, not a
retransmit, we end up updating retransmit path.
RFC4960, section 6.4. "Multi-Homed SCTP Endpoints" states under
6.4.1. "Failover from an Inactive Destination Address" the
following:
Some of the transport addresses of a multi-homed SCTP endpoint
may become inactive due to either the occurrence of certain
error conditions (see Section 8.2) or adjustments from the
SCTP user.
When there is outbound data to send and the primary path
becomes inactive (e.g., due to failures), or where the SCTP
user explicitly requests to send data to an inactive
destination transport address, before reporting an error to
its ULP, the SCTP endpoint should try to send the data to an
alternate __active__ destination transport address if one
exists.
When retransmitting data that timed out, if the endpoint is
multihomed, it should consider each source-destination address
pair in its retransmission selection policy. When retransmitting
timed-out data, the endpoint should attempt to pick the most
divergent source-destination pair from the original
source-destination pair to which the packet was transmitted.
Note: Rules for picking the most divergent source-destination
pair are an implementation decision and are not specified
within this document.
So, we should first reconsider to take the current active
retransmission transport if we cannot find an alternative
active one. If all of that fails, we can still round robin
through unkown, partial failover, and inactive ones in the
hope to find something still suitable.
Commit 4141ddc02a92 ("sctp: retran_path update bug fix") broke
that behaviour by selecting the next inactive transport when
no other active transport was found besides the current assoc's
peer.retran_path. Before commit 4141ddc02a92, we would have
traversed through the list until we reach our peer.retran_path
again, and in case that is still in state SCTP_ACTIVE, we would
take it and return. Only if that is not the case either, we
take the next inactive transport.
Besides all that, another issue is that transports in state
SCTP_UNKNOWN could be preferred over transports in state
SCTP_ACTIVE in case a SCTP_ACTIVE transport appears after
SCTP_UNKNOWN in the transport list yielding a weaker transport
state to be used in retransmission.
This patch mostly reverts 4141ddc02a92, but also rewrites
this function to introduce more clarity and strictness into
the code. A strict priority of transport states is enforced
in this patch, hence selection is active > unkown > partial
failover > inactive.
Fixes: 4141ddc02a92 ("sctp: retran_path update bug fix")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Gui Jianfeng <guijianfeng@cn.fujitsu.com>
Acked-by: Vlad Yasevich <yasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-02-20 19:51:06 +00:00
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
return asoc->peer.retran_path;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Update the association's pmtu and frag_point by going through all the
|
|
|
|
* transports. This routine is called when a transport's PMTU has changed.
|
|
|
|
*/
|
2012-07-16 10:57:14 +00:00
|
|
|
void sctp_assoc_sync_pmtu(struct sock *sk, struct sctp_association *asoc)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct sctp_transport *t;
|
|
|
|
__u32 pmtu = 0;
|
|
|
|
|
|
|
|
if (!asoc)
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Get the lowest pmtu of all the transports. */
|
2008-04-13 01:54:24 +00:00
|
|
|
list_for_each_entry(t, &asoc->peer.transport_addr_list,
|
|
|
|
transports) {
|
2007-06-07 18:21:05 +00:00
|
|
|
if (t->pmtu_pending && t->dst) {
|
2012-07-16 10:57:14 +00:00
|
|
|
sctp_transport_update_pmtu(sk, t, dst_mtu(t->dst));
|
2007-06-07 18:21:05 +00:00
|
|
|
t->pmtu_pending = 0;
|
|
|
|
}
|
2005-12-22 19:36:46 +00:00
|
|
|
if (!pmtu || (t->pathmtu < pmtu))
|
|
|
|
pmtu = t->pathmtu;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
if (pmtu) {
|
2005-12-22 19:36:46 +00:00
|
|
|
asoc->pathmtu = pmtu;
|
2009-09-04 22:21:00 +00:00
|
|
|
asoc->frag_point = sctp_frag_point(asoc, pmtu);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
net: sctp: rework debugging framework to use pr_debug and friends
We should get rid of all own SCTP debug printk macros and use the ones
that the kernel offers anyway instead. This makes the code more readable
and conform to the kernel code, and offers all the features of dynamic
debbuging that pr_debug() et al has, such as only turning on/off portions
of debug messages at runtime through debugfs. The runtime cost of having
CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
is negligible [1]. If kernel debugging is completly turned off, then these
statements will also compile into "empty" functions.
While we're at it, we also need to change the Kconfig option as it /now/
only refers to the ifdef'ed code portions in outqueue.c that enable further
debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
was enabled with this Kconfig option and has now been removed, we
transform those code parts into WARNs resp. where appropriate BUG_ONs so
that those bugs can be more easily detected as probably not many people
have SCTP debugging permanently turned on.
To turn on all SCTP debugging, the following steps are needed:
# mount -t debugfs none /sys/kernel/debug
# echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
This can be done more fine-grained on a per file, per line basis and others
as described in [2].
[1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
[2] Documentation/dynamic-debug-howto.txt
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-28 17:49:40 +00:00
|
|
|
pr_debug("%s: asoc:%p, pmtu:%d, frag_point:%d\n", __func__, asoc,
|
|
|
|
asoc->pathmtu, asoc->frag_point);
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
/* Should we send a SACK to update our peer? */
|
2013-12-06 01:36:29 +00:00
|
|
|
static inline bool sctp_peer_needs_update(struct sctp_association *asoc)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
2012-08-07 07:29:57 +00:00
|
|
|
struct net *net = sock_net(asoc->base.sk);
|
2005-04-16 22:20:36 +00:00
|
|
|
switch (asoc->state) {
|
|
|
|
case SCTP_STATE_ESTABLISHED:
|
|
|
|
case SCTP_STATE_SHUTDOWN_PENDING:
|
|
|
|
case SCTP_STATE_SHUTDOWN_RECEIVED:
|
|
|
|
case SCTP_STATE_SHUTDOWN_SENT:
|
|
|
|
if ((asoc->rwnd > asoc->a_rwnd) &&
|
2009-11-23 20:53:57 +00:00
|
|
|
((asoc->rwnd - asoc->a_rwnd) >= max_t(__u32,
|
2012-08-07 07:29:57 +00:00
|
|
|
(asoc->base.sk->sk_rcvbuf >> net->sctp.rwnd_upd_shift),
|
2009-11-23 20:53:57 +00:00
|
|
|
asoc->pathmtu)))
|
2013-12-06 01:36:29 +00:00
|
|
|
return true;
|
2005-04-16 22:20:36 +00:00
|
|
|
break;
|
|
|
|
default:
|
|
|
|
break;
|
|
|
|
}
|
2013-12-06 01:36:29 +00:00
|
|
|
return false;
|
2005-04-16 22:20:36 +00:00
|
|
|
}
|
|
|
|
|
Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
This reverts commit ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management
to reflect real state of the receiver's buffer") as it introduced a
serious performance regression on SCTP over IPv4 and IPv6, though a not
as dramatic on the latter. Measurements are on 10Gbit/s with ixgbe NICs.
Current state:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.241.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 17:56:21 GMT
Connecting to host 192.168.241.3, port 5201
Cookie: Lab200slot2.1397238981.812898.548918
[ 4] local 192.168.241.2 port 38616 connected to 192.168.241.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.09 sec 20.8 MBytes 161 Mbits/sec
[ 4] 1.09-2.13 sec 10.8 MBytes 86.8 Mbits/sec
[ 4] 2.13-3.15 sec 3.57 MBytes 29.5 Mbits/sec
[ 4] 3.15-4.16 sec 4.33 MBytes 35.7 Mbits/sec
[ 4] 4.16-6.21 sec 10.4 MBytes 42.7 Mbits/sec
[ 4] 6.21-6.21 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.21-7.35 sec 34.6 MBytes 253 Mbits/sec
[ 4] 7.35-11.45 sec 22.0 MBytes 45.0 Mbits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-12.51 sec 16.0 MBytes 126 Mbits/sec
[ 4] 12.51-13.59 sec 20.3 MBytes 158 Mbits/sec
[ 4] 13.59-14.65 sec 13.4 MBytes 107 Mbits/sec
[ 4] 14.65-16.79 sec 33.3 MBytes 130 Mbits/sec
[ 4] 16.79-16.79 sec 0.00 Bytes 0.00 bits/sec
[ 4] 16.79-17.82 sec 5.94 MBytes 48.7 Mbits/sec
(etc)
[root@Lab200slot2 ~]# iperf3 --sctp -6 -c 2001:db8:0:f101::1 -V -l 1400 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 19:08:41 GMT
Connecting to host 2001:db8:0:f101::1, port 5201
Cookie: Lab200slot2.1397243321.714295.2b3f7c
[ 4] local 2001:db8:0:f101::2 port 55804 connected to 2001:db8:0:f101::1 port 5201
Starting Test: protocol: SCTP, 1 streams, 1400 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 169 MBytes 1.42 Gbits/sec
[ 4] 1.00-2.00 sec 201 MBytes 1.69 Gbits/sec
[ 4] 2.00-3.00 sec 188 MBytes 1.58 Gbits/sec
[ 4] 3.00-4.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 4.00-5.00 sec 165 MBytes 1.39 Gbits/sec
[ 4] 5.00-6.00 sec 199 MBytes 1.67 Gbits/sec
[ 4] 6.00-7.00 sec 163 MBytes 1.36 Gbits/sec
[ 4] 7.00-8.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 8.00-9.00 sec 193 MBytes 1.62 Gbits/sec
[ 4] 9.00-10.00 sec 196 MBytes 1.65 Gbits/sec
[ 4] 10.00-11.00 sec 157 MBytes 1.31 Gbits/sec
[ 4] 11.00-12.00 sec 175 MBytes 1.47 Gbits/sec
[ 4] 12.00-13.00 sec 192 MBytes 1.61 Gbits/sec
[ 4] 13.00-14.00 sec 199 MBytes 1.67 Gbits/sec
(etc)
After patch:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.240.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0+ #1 SMP Mon Apr 14 12:06:40 EDT 2014 x86_64
Time: Mon, 14 Apr 2014 16:40:48 GMT
Connecting to host 192.168.240.3, port 5201
Cookie: Lab200slot2.1397493648.413274.65e131
[ 4] local 192.168.240.2 port 50548 connected to 192.168.240.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 1.00-2.00 sec 239 MBytes 2.01 Gbits/sec
[ 4] 2.00-3.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 3.00-4.00 sec 239 MBytes 2.00 Gbits/sec
[ 4] 4.00-5.00 sec 245 MBytes 2.05 Gbits/sec
[ 4] 5.00-6.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 6.00-7.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 7.00-8.00 sec 239 MBytes 2.01 Gbits/sec
With the reverted patch applied, the SCTP/IPv4 performance is back
to normal on latest upstream for IPv4 and IPv6 and has same throughput
as 3.4.2 test kernel, steady and interval reports are smooth again.
Fixes: ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer")
Reported-by: Peter Butler <pbutler@sonusnet.com>
Reported-by: Dongsheng Song <dongsheng.song@gmail.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Peter Butler <pbutler@sonusnet.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-14 19:45:17 +00:00
|
|
|
/* Increase asoc's rwnd by len and send any window update SACK if needed. */
|
|
|
|
void sctp_assoc_rwnd_increase(struct sctp_association *asoc, unsigned int len)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
struct sctp_chunk *sack;
|
|
|
|
struct timer_list *timer;
|
|
|
|
|
Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
This reverts commit ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management
to reflect real state of the receiver's buffer") as it introduced a
serious performance regression on SCTP over IPv4 and IPv6, though a not
as dramatic on the latter. Measurements are on 10Gbit/s with ixgbe NICs.
Current state:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.241.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 17:56:21 GMT
Connecting to host 192.168.241.3, port 5201
Cookie: Lab200slot2.1397238981.812898.548918
[ 4] local 192.168.241.2 port 38616 connected to 192.168.241.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.09 sec 20.8 MBytes 161 Mbits/sec
[ 4] 1.09-2.13 sec 10.8 MBytes 86.8 Mbits/sec
[ 4] 2.13-3.15 sec 3.57 MBytes 29.5 Mbits/sec
[ 4] 3.15-4.16 sec 4.33 MBytes 35.7 Mbits/sec
[ 4] 4.16-6.21 sec 10.4 MBytes 42.7 Mbits/sec
[ 4] 6.21-6.21 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.21-7.35 sec 34.6 MBytes 253 Mbits/sec
[ 4] 7.35-11.45 sec 22.0 MBytes 45.0 Mbits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-12.51 sec 16.0 MBytes 126 Mbits/sec
[ 4] 12.51-13.59 sec 20.3 MBytes 158 Mbits/sec
[ 4] 13.59-14.65 sec 13.4 MBytes 107 Mbits/sec
[ 4] 14.65-16.79 sec 33.3 MBytes 130 Mbits/sec
[ 4] 16.79-16.79 sec 0.00 Bytes 0.00 bits/sec
[ 4] 16.79-17.82 sec 5.94 MBytes 48.7 Mbits/sec
(etc)
[root@Lab200slot2 ~]# iperf3 --sctp -6 -c 2001:db8:0:f101::1 -V -l 1400 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 19:08:41 GMT
Connecting to host 2001:db8:0:f101::1, port 5201
Cookie: Lab200slot2.1397243321.714295.2b3f7c
[ 4] local 2001:db8:0:f101::2 port 55804 connected to 2001:db8:0:f101::1 port 5201
Starting Test: protocol: SCTP, 1 streams, 1400 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 169 MBytes 1.42 Gbits/sec
[ 4] 1.00-2.00 sec 201 MBytes 1.69 Gbits/sec
[ 4] 2.00-3.00 sec 188 MBytes 1.58 Gbits/sec
[ 4] 3.00-4.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 4.00-5.00 sec 165 MBytes 1.39 Gbits/sec
[ 4] 5.00-6.00 sec 199 MBytes 1.67 Gbits/sec
[ 4] 6.00-7.00 sec 163 MBytes 1.36 Gbits/sec
[ 4] 7.00-8.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 8.00-9.00 sec 193 MBytes 1.62 Gbits/sec
[ 4] 9.00-10.00 sec 196 MBytes 1.65 Gbits/sec
[ 4] 10.00-11.00 sec 157 MBytes 1.31 Gbits/sec
[ 4] 11.00-12.00 sec 175 MBytes 1.47 Gbits/sec
[ 4] 12.00-13.00 sec 192 MBytes 1.61 Gbits/sec
[ 4] 13.00-14.00 sec 199 MBytes 1.67 Gbits/sec
(etc)
After patch:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.240.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0+ #1 SMP Mon Apr 14 12:06:40 EDT 2014 x86_64
Time: Mon, 14 Apr 2014 16:40:48 GMT
Connecting to host 192.168.240.3, port 5201
Cookie: Lab200slot2.1397493648.413274.65e131
[ 4] local 192.168.240.2 port 50548 connected to 192.168.240.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 1.00-2.00 sec 239 MBytes 2.01 Gbits/sec
[ 4] 2.00-3.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 3.00-4.00 sec 239 MBytes 2.00 Gbits/sec
[ 4] 4.00-5.00 sec 245 MBytes 2.05 Gbits/sec
[ 4] 5.00-6.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 6.00-7.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 7.00-8.00 sec 239 MBytes 2.01 Gbits/sec
With the reverted patch applied, the SCTP/IPv4 performance is back
to normal on latest upstream for IPv4 and IPv6 and has same throughput
as 3.4.2 test kernel, steady and interval reports are smooth again.
Fixes: ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer")
Reported-by: Peter Butler <pbutler@sonusnet.com>
Reported-by: Dongsheng Song <dongsheng.song@gmail.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Peter Butler <pbutler@sonusnet.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-14 19:45:17 +00:00
|
|
|
if (asoc->rwnd_over) {
|
|
|
|
if (asoc->rwnd_over >= len) {
|
|
|
|
asoc->rwnd_over -= len;
|
|
|
|
} else {
|
|
|
|
asoc->rwnd += (len - asoc->rwnd_over);
|
|
|
|
asoc->rwnd_over = 0;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
asoc->rwnd += len;
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
This reverts commit ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management
to reflect real state of the receiver's buffer") as it introduced a
serious performance regression on SCTP over IPv4 and IPv6, though a not
as dramatic on the latter. Measurements are on 10Gbit/s with ixgbe NICs.
Current state:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.241.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 17:56:21 GMT
Connecting to host 192.168.241.3, port 5201
Cookie: Lab200slot2.1397238981.812898.548918
[ 4] local 192.168.241.2 port 38616 connected to 192.168.241.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.09 sec 20.8 MBytes 161 Mbits/sec
[ 4] 1.09-2.13 sec 10.8 MBytes 86.8 Mbits/sec
[ 4] 2.13-3.15 sec 3.57 MBytes 29.5 Mbits/sec
[ 4] 3.15-4.16 sec 4.33 MBytes 35.7 Mbits/sec
[ 4] 4.16-6.21 sec 10.4 MBytes 42.7 Mbits/sec
[ 4] 6.21-6.21 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.21-7.35 sec 34.6 MBytes 253 Mbits/sec
[ 4] 7.35-11.45 sec 22.0 MBytes 45.0 Mbits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-12.51 sec 16.0 MBytes 126 Mbits/sec
[ 4] 12.51-13.59 sec 20.3 MBytes 158 Mbits/sec
[ 4] 13.59-14.65 sec 13.4 MBytes 107 Mbits/sec
[ 4] 14.65-16.79 sec 33.3 MBytes 130 Mbits/sec
[ 4] 16.79-16.79 sec 0.00 Bytes 0.00 bits/sec
[ 4] 16.79-17.82 sec 5.94 MBytes 48.7 Mbits/sec
(etc)
[root@Lab200slot2 ~]# iperf3 --sctp -6 -c 2001:db8:0:f101::1 -V -l 1400 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 19:08:41 GMT
Connecting to host 2001:db8:0:f101::1, port 5201
Cookie: Lab200slot2.1397243321.714295.2b3f7c
[ 4] local 2001:db8:0:f101::2 port 55804 connected to 2001:db8:0:f101::1 port 5201
Starting Test: protocol: SCTP, 1 streams, 1400 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 169 MBytes 1.42 Gbits/sec
[ 4] 1.00-2.00 sec 201 MBytes 1.69 Gbits/sec
[ 4] 2.00-3.00 sec 188 MBytes 1.58 Gbits/sec
[ 4] 3.00-4.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 4.00-5.00 sec 165 MBytes 1.39 Gbits/sec
[ 4] 5.00-6.00 sec 199 MBytes 1.67 Gbits/sec
[ 4] 6.00-7.00 sec 163 MBytes 1.36 Gbits/sec
[ 4] 7.00-8.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 8.00-9.00 sec 193 MBytes 1.62 Gbits/sec
[ 4] 9.00-10.00 sec 196 MBytes 1.65 Gbits/sec
[ 4] 10.00-11.00 sec 157 MBytes 1.31 Gbits/sec
[ 4] 11.00-12.00 sec 175 MBytes 1.47 Gbits/sec
[ 4] 12.00-13.00 sec 192 MBytes 1.61 Gbits/sec
[ 4] 13.00-14.00 sec 199 MBytes 1.67 Gbits/sec
(etc)
After patch:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.240.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0+ #1 SMP Mon Apr 14 12:06:40 EDT 2014 x86_64
Time: Mon, 14 Apr 2014 16:40:48 GMT
Connecting to host 192.168.240.3, port 5201
Cookie: Lab200slot2.1397493648.413274.65e131
[ 4] local 192.168.240.2 port 50548 connected to 192.168.240.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 1.00-2.00 sec 239 MBytes 2.01 Gbits/sec
[ 4] 2.00-3.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 3.00-4.00 sec 239 MBytes 2.00 Gbits/sec
[ 4] 4.00-5.00 sec 245 MBytes 2.05 Gbits/sec
[ 4] 5.00-6.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 6.00-7.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 7.00-8.00 sec 239 MBytes 2.01 Gbits/sec
With the reverted patch applied, the SCTP/IPv4 performance is back
to normal on latest upstream for IPv4 and IPv6 and has same throughput
as 3.4.2 test kernel, steady and interval reports are smooth again.
Fixes: ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer")
Reported-by: Peter Butler <pbutler@sonusnet.com>
Reported-by: Dongsheng Song <dongsheng.song@gmail.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Peter Butler <pbutler@sonusnet.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-14 19:45:17 +00:00
|
|
|
/* If we had window pressure, start recovering it
|
|
|
|
* once our rwnd had reached the accumulated pressure
|
|
|
|
* threshold. The idea is to recover slowly, but up
|
|
|
|
* to the initial advertised window.
|
|
|
|
*/
|
|
|
|
if (asoc->rwnd_press && asoc->rwnd >= asoc->rwnd_press) {
|
|
|
|
int change = min(asoc->pathmtu, asoc->rwnd_press);
|
|
|
|
asoc->rwnd += change;
|
|
|
|
asoc->rwnd_press -= change;
|
|
|
|
}
|
2009-09-04 22:20:59 +00:00
|
|
|
|
Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
This reverts commit ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management
to reflect real state of the receiver's buffer") as it introduced a
serious performance regression on SCTP over IPv4 and IPv6, though a not
as dramatic on the latter. Measurements are on 10Gbit/s with ixgbe NICs.
Current state:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.241.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 17:56:21 GMT
Connecting to host 192.168.241.3, port 5201
Cookie: Lab200slot2.1397238981.812898.548918
[ 4] local 192.168.241.2 port 38616 connected to 192.168.241.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.09 sec 20.8 MBytes 161 Mbits/sec
[ 4] 1.09-2.13 sec 10.8 MBytes 86.8 Mbits/sec
[ 4] 2.13-3.15 sec 3.57 MBytes 29.5 Mbits/sec
[ 4] 3.15-4.16 sec 4.33 MBytes 35.7 Mbits/sec
[ 4] 4.16-6.21 sec 10.4 MBytes 42.7 Mbits/sec
[ 4] 6.21-6.21 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.21-7.35 sec 34.6 MBytes 253 Mbits/sec
[ 4] 7.35-11.45 sec 22.0 MBytes 45.0 Mbits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-12.51 sec 16.0 MBytes 126 Mbits/sec
[ 4] 12.51-13.59 sec 20.3 MBytes 158 Mbits/sec
[ 4] 13.59-14.65 sec 13.4 MBytes 107 Mbits/sec
[ 4] 14.65-16.79 sec 33.3 MBytes 130 Mbits/sec
[ 4] 16.79-16.79 sec 0.00 Bytes 0.00 bits/sec
[ 4] 16.79-17.82 sec 5.94 MBytes 48.7 Mbits/sec
(etc)
[root@Lab200slot2 ~]# iperf3 --sctp -6 -c 2001:db8:0:f101::1 -V -l 1400 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 19:08:41 GMT
Connecting to host 2001:db8:0:f101::1, port 5201
Cookie: Lab200slot2.1397243321.714295.2b3f7c
[ 4] local 2001:db8:0:f101::2 port 55804 connected to 2001:db8:0:f101::1 port 5201
Starting Test: protocol: SCTP, 1 streams, 1400 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 169 MBytes 1.42 Gbits/sec
[ 4] 1.00-2.00 sec 201 MBytes 1.69 Gbits/sec
[ 4] 2.00-3.00 sec 188 MBytes 1.58 Gbits/sec
[ 4] 3.00-4.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 4.00-5.00 sec 165 MBytes 1.39 Gbits/sec
[ 4] 5.00-6.00 sec 199 MBytes 1.67 Gbits/sec
[ 4] 6.00-7.00 sec 163 MBytes 1.36 Gbits/sec
[ 4] 7.00-8.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 8.00-9.00 sec 193 MBytes 1.62 Gbits/sec
[ 4] 9.00-10.00 sec 196 MBytes 1.65 Gbits/sec
[ 4] 10.00-11.00 sec 157 MBytes 1.31 Gbits/sec
[ 4] 11.00-12.00 sec 175 MBytes 1.47 Gbits/sec
[ 4] 12.00-13.00 sec 192 MBytes 1.61 Gbits/sec
[ 4] 13.00-14.00 sec 199 MBytes 1.67 Gbits/sec
(etc)
After patch:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.240.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0+ #1 SMP Mon Apr 14 12:06:40 EDT 2014 x86_64
Time: Mon, 14 Apr 2014 16:40:48 GMT
Connecting to host 192.168.240.3, port 5201
Cookie: Lab200slot2.1397493648.413274.65e131
[ 4] local 192.168.240.2 port 50548 connected to 192.168.240.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 1.00-2.00 sec 239 MBytes 2.01 Gbits/sec
[ 4] 2.00-3.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 3.00-4.00 sec 239 MBytes 2.00 Gbits/sec
[ 4] 4.00-5.00 sec 245 MBytes 2.05 Gbits/sec
[ 4] 5.00-6.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 6.00-7.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 7.00-8.00 sec 239 MBytes 2.01 Gbits/sec
With the reverted patch applied, the SCTP/IPv4 performance is back
to normal on latest upstream for IPv4 and IPv6 and has same throughput
as 3.4.2 test kernel, steady and interval reports are smooth again.
Fixes: ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer")
Reported-by: Peter Butler <pbutler@sonusnet.com>
Reported-by: Dongsheng Song <dongsheng.song@gmail.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Peter Butler <pbutler@sonusnet.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-14 19:45:17 +00:00
|
|
|
pr_debug("%s: asoc:%p rwnd increased by %d to (%u, %u) - %u\n",
|
|
|
|
__func__, asoc, len, asoc->rwnd, asoc->rwnd_over,
|
|
|
|
asoc->a_rwnd);
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Send a window update SACK if the rwnd has increased by at least the
|
|
|
|
* minimum of the association's PMTU and half of the receive buffer.
|
|
|
|
* The algorithm used is similar to the one described in
|
|
|
|
* Section 4.2.3.3 of RFC 1122.
|
|
|
|
*/
|
Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
This reverts commit ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management
to reflect real state of the receiver's buffer") as it introduced a
serious performance regression on SCTP over IPv4 and IPv6, though a not
as dramatic on the latter. Measurements are on 10Gbit/s with ixgbe NICs.
Current state:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.241.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 17:56:21 GMT
Connecting to host 192.168.241.3, port 5201
Cookie: Lab200slot2.1397238981.812898.548918
[ 4] local 192.168.241.2 port 38616 connected to 192.168.241.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.09 sec 20.8 MBytes 161 Mbits/sec
[ 4] 1.09-2.13 sec 10.8 MBytes 86.8 Mbits/sec
[ 4] 2.13-3.15 sec 3.57 MBytes 29.5 Mbits/sec
[ 4] 3.15-4.16 sec 4.33 MBytes 35.7 Mbits/sec
[ 4] 4.16-6.21 sec 10.4 MBytes 42.7 Mbits/sec
[ 4] 6.21-6.21 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.21-7.35 sec 34.6 MBytes 253 Mbits/sec
[ 4] 7.35-11.45 sec 22.0 MBytes 45.0 Mbits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-12.51 sec 16.0 MBytes 126 Mbits/sec
[ 4] 12.51-13.59 sec 20.3 MBytes 158 Mbits/sec
[ 4] 13.59-14.65 sec 13.4 MBytes 107 Mbits/sec
[ 4] 14.65-16.79 sec 33.3 MBytes 130 Mbits/sec
[ 4] 16.79-16.79 sec 0.00 Bytes 0.00 bits/sec
[ 4] 16.79-17.82 sec 5.94 MBytes 48.7 Mbits/sec
(etc)
[root@Lab200slot2 ~]# iperf3 --sctp -6 -c 2001:db8:0:f101::1 -V -l 1400 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 19:08:41 GMT
Connecting to host 2001:db8:0:f101::1, port 5201
Cookie: Lab200slot2.1397243321.714295.2b3f7c
[ 4] local 2001:db8:0:f101::2 port 55804 connected to 2001:db8:0:f101::1 port 5201
Starting Test: protocol: SCTP, 1 streams, 1400 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 169 MBytes 1.42 Gbits/sec
[ 4] 1.00-2.00 sec 201 MBytes 1.69 Gbits/sec
[ 4] 2.00-3.00 sec 188 MBytes 1.58 Gbits/sec
[ 4] 3.00-4.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 4.00-5.00 sec 165 MBytes 1.39 Gbits/sec
[ 4] 5.00-6.00 sec 199 MBytes 1.67 Gbits/sec
[ 4] 6.00-7.00 sec 163 MBytes 1.36 Gbits/sec
[ 4] 7.00-8.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 8.00-9.00 sec 193 MBytes 1.62 Gbits/sec
[ 4] 9.00-10.00 sec 196 MBytes 1.65 Gbits/sec
[ 4] 10.00-11.00 sec 157 MBytes 1.31 Gbits/sec
[ 4] 11.00-12.00 sec 175 MBytes 1.47 Gbits/sec
[ 4] 12.00-13.00 sec 192 MBytes 1.61 Gbits/sec
[ 4] 13.00-14.00 sec 199 MBytes 1.67 Gbits/sec
(etc)
After patch:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.240.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0+ #1 SMP Mon Apr 14 12:06:40 EDT 2014 x86_64
Time: Mon, 14 Apr 2014 16:40:48 GMT
Connecting to host 192.168.240.3, port 5201
Cookie: Lab200slot2.1397493648.413274.65e131
[ 4] local 192.168.240.2 port 50548 connected to 192.168.240.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 1.00-2.00 sec 239 MBytes 2.01 Gbits/sec
[ 4] 2.00-3.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 3.00-4.00 sec 239 MBytes 2.00 Gbits/sec
[ 4] 4.00-5.00 sec 245 MBytes 2.05 Gbits/sec
[ 4] 5.00-6.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 6.00-7.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 7.00-8.00 sec 239 MBytes 2.01 Gbits/sec
With the reverted patch applied, the SCTP/IPv4 performance is back
to normal on latest upstream for IPv4 and IPv6 and has same throughput
as 3.4.2 test kernel, steady and interval reports are smooth again.
Fixes: ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer")
Reported-by: Peter Butler <pbutler@sonusnet.com>
Reported-by: Dongsheng Song <dongsheng.song@gmail.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Peter Butler <pbutler@sonusnet.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-14 19:45:17 +00:00
|
|
|
if (sctp_peer_needs_update(asoc)) {
|
2005-04-16 22:20:36 +00:00
|
|
|
asoc->a_rwnd = asoc->rwnd;
|
net: sctp: rework debugging framework to use pr_debug and friends
We should get rid of all own SCTP debug printk macros and use the ones
that the kernel offers anyway instead. This makes the code more readable
and conform to the kernel code, and offers all the features of dynamic
debbuging that pr_debug() et al has, such as only turning on/off portions
of debug messages at runtime through debugfs. The runtime cost of having
CONFIG_DYNAMIC_DEBUG enabled, but none of the debug statements printing,
is negligible [1]. If kernel debugging is completly turned off, then these
statements will also compile into "empty" functions.
While we're at it, we also need to change the Kconfig option as it /now/
only refers to the ifdef'ed code portions in outqueue.c that enable further
debugging/tracing of SCTP transaction fields. Also, since SCTP_ASSERT code
was enabled with this Kconfig option and has now been removed, we
transform those code parts into WARNs resp. where appropriate BUG_ONs so
that those bugs can be more easily detected as probably not many people
have SCTP debugging permanently turned on.
To turn on all SCTP debugging, the following steps are needed:
# mount -t debugfs none /sys/kernel/debug
# echo -n 'module sctp +p' > /sys/kernel/debug/dynamic_debug/control
This can be done more fine-grained on a per file, per line basis and others
as described in [2].
[1] https://www.kernel.org/doc/ols/2009/ols2009-pages-39-46.pdf
[2] Documentation/dynamic-debug-howto.txt
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2013-06-28 17:49:40 +00:00
|
|
|
|
|
|
|
pr_debug("%s: sending window update SACK- asoc:%p rwnd:%u "
|
|
|
|
"a_rwnd:%u\n", __func__, asoc, asoc->rwnd,
|
|
|
|
asoc->a_rwnd);
|
|
|
|
|
2005-04-16 22:20:36 +00:00
|
|
|
sack = sctp_make_sack(asoc);
|
|
|
|
if (!sack)
|
|
|
|
return;
|
|
|
|
|
|
|
|
asoc->peer.sack_needed = 0;
|
|
|
|
|
|
|
|
sctp_outq_tail(&asoc->outqueue, sack);
|
|
|
|
|
|
|
|
/* Stop the SACK timer. */
|
|
|
|
timer = &asoc->timers[SCTP_EVENT_TIMEOUT_SACK];
|
2013-02-03 20:32:57 +00:00
|
|
|
if (del_timer(timer))
|
2005-04-16 22:20:36 +00:00
|
|
|
sctp_association_put(asoc);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
Revert "net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer"
This reverts commit ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management
to reflect real state of the receiver's buffer") as it introduced a
serious performance regression on SCTP over IPv4 and IPv6, though a not
as dramatic on the latter. Measurements are on 10Gbit/s with ixgbe NICs.
Current state:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.241.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 17:56:21 GMT
Connecting to host 192.168.241.3, port 5201
Cookie: Lab200slot2.1397238981.812898.548918
[ 4] local 192.168.241.2 port 38616 connected to 192.168.241.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.09 sec 20.8 MBytes 161 Mbits/sec
[ 4] 1.09-2.13 sec 10.8 MBytes 86.8 Mbits/sec
[ 4] 2.13-3.15 sec 3.57 MBytes 29.5 Mbits/sec
[ 4] 3.15-4.16 sec 4.33 MBytes 35.7 Mbits/sec
[ 4] 4.16-6.21 sec 10.4 MBytes 42.7 Mbits/sec
[ 4] 6.21-6.21 sec 0.00 Bytes 0.00 bits/sec
[ 4] 6.21-7.35 sec 34.6 MBytes 253 Mbits/sec
[ 4] 7.35-11.45 sec 22.0 MBytes 45.0 Mbits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-11.45 sec 0.00 Bytes 0.00 bits/sec
[ 4] 11.45-12.51 sec 16.0 MBytes 126 Mbits/sec
[ 4] 12.51-13.59 sec 20.3 MBytes 158 Mbits/sec
[ 4] 13.59-14.65 sec 13.4 MBytes 107 Mbits/sec
[ 4] 14.65-16.79 sec 33.3 MBytes 130 Mbits/sec
[ 4] 16.79-16.79 sec 0.00 Bytes 0.00 bits/sec
[ 4] 16.79-17.82 sec 5.94 MBytes 48.7 Mbits/sec
(etc)
[root@Lab200slot2 ~]# iperf3 --sctp -6 -c 2001:db8:0:f101::1 -V -l 1400 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0 #1 SMP Thu Apr 3 23:18:29 EDT 2014 x86_64
Time: Fri, 11 Apr 2014 19:08:41 GMT
Connecting to host 2001:db8:0:f101::1, port 5201
Cookie: Lab200slot2.1397243321.714295.2b3f7c
[ 4] local 2001:db8:0:f101::2 port 55804 connected to 2001:db8:0:f101::1 port 5201
Starting Test: protocol: SCTP, 1 streams, 1400 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 169 MBytes 1.42 Gbits/sec
[ 4] 1.00-2.00 sec 201 MBytes 1.69 Gbits/sec
[ 4] 2.00-3.00 sec 188 MBytes 1.58 Gbits/sec
[ 4] 3.00-4.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 4.00-5.00 sec 165 MBytes 1.39 Gbits/sec
[ 4] 5.00-6.00 sec 199 MBytes 1.67 Gbits/sec
[ 4] 6.00-7.00 sec 163 MBytes 1.36 Gbits/sec
[ 4] 7.00-8.00 sec 174 MBytes 1.46 Gbits/sec
[ 4] 8.00-9.00 sec 193 MBytes 1.62 Gbits/sec
[ 4] 9.00-10.00 sec 196 MBytes 1.65 Gbits/sec
[ 4] 10.00-11.00 sec 157 MBytes 1.31 Gbits/sec
[ 4] 11.00-12.00 sec 175 MBytes 1.47 Gbits/sec
[ 4] 12.00-13.00 sec 192 MBytes 1.61 Gbits/sec
[ 4] 13.00-14.00 sec 199 MBytes 1.67 Gbits/sec
(etc)
After patch:
[root@Lab200slot2 ~]# iperf3 --sctp -4 -c 192.168.240.3 -V -l 1452 -t 60
iperf version 3.0.1 (10 January 2014)
Linux Lab200slot2 3.14.0+ #1 SMP Mon Apr 14 12:06:40 EDT 2014 x86_64
Time: Mon, 14 Apr 2014 16:40:48 GMT
Connecting to host 192.168.240.3, port 5201
Cookie: Lab200slot2.1397493648.413274.65e131
[ 4] local 192.168.240.2 port 50548 connected to 192.168.240.3 port 5201
Starting Test: protocol: SCTP, 1 streams, 1452 byte blocks, omitting 0 seconds, 60 second test
[ ID] Interval Transfer Bandwidth
[ 4] 0.00-1.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 1.00-2.00 sec 239 MBytes 2.01 Gbits/sec
[ 4] 2.00-3.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 3.00-4.00 sec 239 MBytes 2.00 Gbits/sec
[ 4] 4.00-5.00 sec 245 MBytes 2.05 Gbits/sec
[ 4] 5.00-6.00 sec 240 MBytes 2.01 Gbits/sec
[ 4] 6.00-7.00 sec 240 MBytes 2.02 Gbits/sec
[ 4] 7.00-8.00 sec 239 MBytes 2.01 Gbits/sec
With the reverted patch applied, the SCTP/IPv4 performance is back
to normal on latest upstream for IPv4 and IPv6 and has same throughput
as 3.4.2 test kernel, steady and interval reports are smooth again.
Fixes: ef2820a735f7 ("net: sctp: Fix a_rwnd/rwnd management to reflect real state of the receiver's buffer")
Reported-by: Peter Butler <pbutler@sonusnet.com>
Reported-by: Dongsheng Song <dongsheng.song@gmail.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Tested-by: Peter Butler <pbutler@sonusnet.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Matija Glavinic Pecotic <matija.glavinic-pecotic.ext@nsn.com>
Cc: Alexander Sverdlin <alexander.sverdlin@nsn.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-04-14 19:45:17 +00:00
|
|
|
/* Decrease asoc's rwnd by len. */
|
|
|
|
void sctp_assoc_rwnd_decrease(struct sctp_association *asoc, unsigned int len)
|
|
|
|
{
|
|
|
|
int rx_count;
|
|
|
|
int over = 0;
|
|
|
|
|
|
|
|
if (unlikely(!asoc->rwnd || asoc->rwnd_over))
|
|
|
|
pr_debug("%s: association:%p has asoc->rwnd:%u, "
|
|
|
|
"asoc->rwnd_over:%u!\n", __func__, asoc,
|
|
|
|
asoc->rwnd, asoc->rwnd_over);
|
|
|
|
|
|
|
|
if (asoc->ep->rcvbuf_policy)
|
|
|
|
rx_count = atomic_read(&asoc->rmem_alloc);
|
|
|
|
else
|
|
|
|
rx_count = atomic_read(&asoc->base.sk->sk_rmem_alloc);
|
|
|
|
|
|
|
|
/* If we've reached or overflowed our receive buffer, announce
|
|
|
|
* a 0 rwnd if rwnd would still be positive. Store the
|
|
|
|
* the potential pressure overflow so that the window can be restored
|
|
|
|
* back to original value.
|
|
|
|
*/
|
|
|
|
if (rx_count >= asoc->base.sk->sk_rcvbuf)
|
|
|
|
over = 1;
|
|
|
|
|
|
|
|
if (asoc->rwnd >= len) {
|
|
|
|
asoc->rwnd -= len;
|
|
|
|
if (over) {
|
|
|
|
asoc->rwnd_press += asoc->rwnd;
|
|
|
|
asoc->rwnd = 0;
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
asoc->rwnd_over = len - asoc->rwnd;
|
|
|
|
asoc->rwnd = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
pr_debug("%s: asoc:%p rwnd decreased by %d to (%u, %u, %u)\n",
|
|
|
|
__func__, asoc, len, asoc->rwnd, asoc->rwnd_over,
|
|
|
|
asoc->rwnd_press);
|
|
|
|
}
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
/* Build the bind address list for the association based on info from the
|
|
|
|
* local endpoint and the remote peer.
|
|
|
|
*/
|
2005-07-12 03:57:47 +00:00
|
|
|
int sctp_assoc_set_bind_addr_from_ep(struct sctp_association *asoc,
|
2009-11-10 08:57:34 +00:00
|
|
|
sctp_scope_t scope, gfp_t gfp)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
int flags;
|
|
|
|
|
|
|
|
/* Use scoping rules to determine the subset of addresses from
|
|
|
|
* the endpoint.
|
|
|
|
*/
|
|
|
|
flags = (PF_INET6 == asoc->base.sk->sk_family) ? SCTP_ADDR6_ALLOWED : 0;
|
|
|
|
if (asoc->peer.ipv4_address)
|
|
|
|
flags |= SCTP_ADDR4_PEERSUPP;
|
|
|
|
if (asoc->peer.ipv6_address)
|
|
|
|
flags |= SCTP_ADDR6_PEERSUPP;
|
|
|
|
|
2012-08-06 08:42:04 +00:00
|
|
|
return sctp_bind_addr_copy(sock_net(asoc->base.sk),
|
|
|
|
&asoc->base.bind_addr,
|
2005-04-16 22:20:36 +00:00
|
|
|
&asoc->ep->base.bind_addr,
|
|
|
|
scope, gfp, flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Build the association's bind address list from the cookie. */
|
|
|
|
int sctp_assoc_set_bind_addr_from_cookie(struct sctp_association *asoc,
|
2005-07-12 03:57:47 +00:00
|
|
|
struct sctp_cookie *cookie,
|
2005-10-07 06:46:04 +00:00
|
|
|
gfp_t gfp)
|
2005-04-16 22:20:36 +00:00
|
|
|
{
|
|
|
|
int var_size2 = ntohs(cookie->peer_init->chunk_hdr.length);
|
|
|
|
int var_size3 = cookie->raw_addr_list_len;
|
|
|
|
__u8 *raw = (__u8 *)cookie->peer_init + var_size2;
|
|
|
|
|
|
|
|
return sctp_raw_to_bind_addrs(&asoc->base.bind_addr, raw, var_size3,
|
|
|
|
asoc->ep->base.bind_addr.port, gfp);
|
|
|
|
}
|
|
|
|
|
2007-02-09 14:25:18 +00:00
|
|
|
/* Lookup laddr in the bind address list of an association. */
|
|
|
|
int sctp_assoc_lookup_laddr(struct sctp_association *asoc,
|
2005-04-16 22:20:36 +00:00
|
|
|
const union sctp_addr *laddr)
|
|
|
|
{
|
2007-09-16 23:03:28 +00:00
|
|
|
int found = 0;
|
2005-04-16 22:20:36 +00:00
|
|
|
|
|
|
|
if ((asoc->base.bind_addr.port == ntohs(laddr->v4.sin_port)) &&
|
|
|
|
sctp_bind_addr_match(&asoc->base.bind_addr, laddr,
|
2007-09-16 23:03:28 +00:00
|
|
|
sctp_sk(asoc->base.sk)))
|
2005-04-16 22:20:36 +00:00
|
|
|
found = 1;
|
|
|
|
|
|
|
|
return found;
|
|
|
|
}
|
2007-05-04 20:55:27 +00:00
|
|
|
|
|
|
|
/* Set an association id for a given association */
|
|
|
|
int sctp_assoc_set_id(struct sctp_association *asoc, gfp_t gfp)
|
|
|
|
{
|
2014-06-11 16:19:32 +00:00
|
|
|
bool preload = !!(gfp & __GFP_WAIT);
|
2013-02-28 01:05:00 +00:00
|
|
|
int ret;
|
2009-06-01 16:41:15 +00:00
|
|
|
|
|
|
|
/* If the id is already assigned, keep it. */
|
|
|
|
if (asoc->assoc_id)
|
2013-02-28 01:05:00 +00:00
|
|
|
return 0;
|
2007-05-04 20:55:27 +00:00
|
|
|
|
2013-02-28 01:05:00 +00:00
|
|
|
if (preload)
|
|
|
|
idr_preload(gfp);
|
2007-05-04 20:55:27 +00:00
|
|
|
spin_lock_bh(&sctp_assocs_id_lock);
|
2013-04-29 23:21:22 +00:00
|
|
|
/* 0 is not a valid assoc_id, must be >= 1 */
|
|
|
|
ret = idr_alloc_cyclic(&sctp_assocs_id, asoc, 1, 0, GFP_NOWAIT);
|
2007-05-04 20:55:27 +00:00
|
|
|
spin_unlock_bh(&sctp_assocs_id_lock);
|
2013-02-28 01:05:00 +00:00
|
|
|
if (preload)
|
|
|
|
idr_preload_end();
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
2007-05-04 20:55:27 +00:00
|
|
|
|
2013-02-28 01:05:00 +00:00
|
|
|
asoc->assoc_id = (sctp_assoc_t)ret;
|
|
|
|
return 0;
|
2007-05-04 20:55:27 +00:00
|
|
|
}
|
2007-12-20 22:11:47 +00:00
|
|
|
|
2011-05-24 21:48:02 +00:00
|
|
|
/* Free the ASCONF queue */
|
|
|
|
static void sctp_assoc_free_asconf_queue(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
struct sctp_chunk *asconf;
|
|
|
|
struct sctp_chunk *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(asconf, tmp, &asoc->addip_chunk_list, list) {
|
|
|
|
list_del_init(&asconf->list);
|
|
|
|
sctp_chunk_free(asconf);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2007-12-20 22:11:47 +00:00
|
|
|
/* Free asconf_ack cache */
|
|
|
|
static void sctp_assoc_free_asconf_acks(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
struct sctp_chunk *ack;
|
|
|
|
struct sctp_chunk *tmp;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(ack, tmp, &asoc->asconf_ack_list,
|
|
|
|
transmitted_list) {
|
|
|
|
list_del_init(&ack->transmitted_list);
|
|
|
|
sctp_chunk_free(ack);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Clean up the ASCONF_ACK queue */
|
|
|
|
void sctp_assoc_clean_asconf_ack_cache(const struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
struct sctp_chunk *ack;
|
|
|
|
struct sctp_chunk *tmp;
|
|
|
|
|
2011-03-31 01:57:33 +00:00
|
|
|
/* We can remove all the entries from the queue up to
|
2007-12-20 22:11:47 +00:00
|
|
|
* the "Peer-Sequence-Number".
|
|
|
|
*/
|
|
|
|
list_for_each_entry_safe(ack, tmp, &asoc->asconf_ack_list,
|
|
|
|
transmitted_list) {
|
|
|
|
if (ack->subh.addip_hdr->serial ==
|
|
|
|
htonl(asoc->peer.addip_serial))
|
|
|
|
break;
|
|
|
|
|
|
|
|
list_del_init(&ack->transmitted_list);
|
|
|
|
sctp_chunk_free(ack);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Find the ASCONF_ACK whose serial number matches ASCONF */
|
|
|
|
struct sctp_chunk *sctp_assoc_lookup_asconf_ack(
|
|
|
|
const struct sctp_association *asoc,
|
|
|
|
__be32 serial)
|
|
|
|
{
|
2008-02-05 14:35:04 +00:00
|
|
|
struct sctp_chunk *ack;
|
2007-12-20 22:11:47 +00:00
|
|
|
|
|
|
|
/* Walk through the list of cached ASCONF-ACKs and find the
|
|
|
|
* ack chunk whose serial number matches that of the request.
|
|
|
|
*/
|
|
|
|
list_for_each_entry(ack, &asoc->asconf_ack_list, transmitted_list) {
|
|
|
|
if (ack->subh.addip_hdr->serial == serial) {
|
|
|
|
sctp_chunk_hold(ack);
|
2008-02-05 14:35:04 +00:00
|
|
|
return ack;
|
2007-12-20 22:11:47 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-02-05 14:35:04 +00:00
|
|
|
return NULL;
|
2007-12-20 22:11:47 +00:00
|
|
|
}
|
2011-05-29 23:23:36 +00:00
|
|
|
|
|
|
|
void sctp_asconf_queue_teardown(struct sctp_association *asoc)
|
|
|
|
{
|
|
|
|
/* Free any cached ASCONF_ACK chunk. */
|
|
|
|
sctp_assoc_free_asconf_acks(asoc);
|
|
|
|
|
|
|
|
/* Free the ASCONF queue. */
|
|
|
|
sctp_assoc_free_asconf_queue(asoc);
|
|
|
|
|
|
|
|
/* Free any cached ASCONF chunk. */
|
|
|
|
if (asoc->addip_last_asconf)
|
|
|
|
sctp_chunk_free(asoc->addip_last_asconf);
|
|
|
|
}
|