2019-05-23 12:14:41 +03:00
// SPDX-License-Identifier: GPL-2.0-or-later
2008-01-11 17:57:09 +03:00
/* SCTP kernel implementation
2005-04-17 02:20:36 +04: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 17:57:09 +03:00
* This file is part of the SCTP kernel implementation
2005-04-17 02:20:36 +04:00
*
* This module provides the abstraction for an SCTP association .
*
* Please send any bug reports or fixes you make to the
* email address ( es ) :
2013-07-23 16:51:47 +04:00
* lksctp developers < linux - sctp @ vger . kernel . org >
2005-04-17 02:20:36 +04: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 17:21:08 +04:00
# define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
2005-04-17 02:20:36 +04: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 20:19:29 +04:00
static void sctp_select_active_and_retran_path ( struct sctp_association * asoc ) ;
2006-11-22 17:57:56 +03:00
static void sctp_assoc_bh_rcv ( struct work_struct * work ) ;
2007-12-21 01:11:47 +03:00
static void sctp_assoc_free_asconf_acks ( struct sctp_association * asoc ) ;
2011-05-25 01:48:02 +04:00
static void sctp_assoc_free_asconf_queue ( struct sctp_association * asoc ) ;
2005-04-17 02:20:36 +04:00
/* 1st Level Abstractions. */
/* Initialize a new association from provided memory. */
2017-08-05 14:59:54 +03:00
static struct sctp_association * sctp_association_init (
struct sctp_association * asoc ,
const struct sctp_endpoint * ep ,
const struct sock * sk ,
enum sctp_scope scope , gfp_t gfp )
2005-04-17 02:20:36 +04:00
{
struct sctp_sock * sp ;
2017-06-30 06:52:16 +03:00
struct sctp_paramhdr * p ;
2017-03-20 13:00:28 +03:00
int i ;
2005-04-17 02:20:36 +04: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 ;
2019-11-23 06:56:49 +03:00
asoc - > base . net = sock_net ( sk ) ;
2013-06-14 20:24:07 +04:00
sctp_endpoint_hold ( asoc - > ep ) ;
2005-04-17 02:20:36 +04:00
sock_hold ( asoc - > base . sk ) ;
/* Initialize the common base substructure. */
asoc - > base . type = SCTP_EP_TYPE_ASSOCIATION ;
/* Initialize the object handling fields. */
2017-07-04 15:53:28 +03:00
refcount_set ( & asoc - > base . refcnt , 1 ) ;
2005-04-17 02:20:36 +04:00
/* 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 20:17:27 +04:00
asoc - > cookie_life = ms_to_ktime ( sp - > assocparams . sasoc_cookie_life ) ;
2009-09-05 02:21:00 +04:00
asoc - > user_frag = sp - > user_frag ;
2005-04-17 02:20:36 +04:00
/* Set the association max_retrans and RTO values from the
* socket values .
*/
asoc - > max_retrans = sp - > assocparams . sasoc_asocmaxrxt ;
2019-01-28 10:08:29 +03:00
asoc - > pf_retrans = sp - > pf_retrans ;
2019-11-08 08:20:35 +03:00
asoc - > ps_retrans = sp - > ps_retrans ;
sctp: add pf_expose per netns and sock and asoc
As said in rfc7829, section 3, point 12:
The SCTP stack SHOULD expose the PF state of its destination
addresses to the ULP as well as provide the means to notify the
ULP of state transitions of its destination addresses from
active to PF, and vice versa. However, it is recommended that
an SCTP stack implementing SCTP-PF also allows for the ULP to be
kept ignorant of the PF state of its destinations and the
associated state transitions, thus allowing for retention of the
simpler state transition model of [RFC4960] in the ULP.
Not only does it allow to expose the PF state to ULP, but also
allow to ignore sctp-pf to ULP.
So this patch is to add pf_expose per netns, sock and asoc. And in
sctp_assoc_control_transport(), ulp_notify will be set to false if
asoc->expose is not 'enabled' in next patch.
It also allows a user to change pf_expose per netns by sysctl, and
pf_expose per sock and asoc will be initialized with it.
Note that pf_expose also works for SCTP_GET_PEER_ADDR_INFO sockopt,
to not allow a user to query the state of a sctp-pf peer address
when pf_expose is 'disabled', as said in section 7.3.
v1->v2:
- Fix a build warning noticed by Nathan Chancellor.
v2->v3:
- set pf_expose to UNUSED by default to keep compatible with old
applications.
v3->v4:
- add a new entry for pf_expose on ip-sysctl.txt, as Marcelo suggested.
- change this patch to 1/5, and move sctp_assoc_control_transport
change into 2/5, as Marcelo suggested.
- use SCTP_PF_EXPOSE_UNSET instead of SCTP_PF_EXPOSE_UNUSED, and
set SCTP_PF_EXPOSE_UNSET to 0 in enum, as Marcelo suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 08:20:32 +03:00
asoc - > pf_expose = sp - > pf_expose ;
2012-07-21 11:56:07 +04:00
2005-04-17 02:20:36 +04: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 22:36:46 +03:00
/* Initialize the association's heartbeat interval based on the
* sock configured value .
*/
asoc - > hbinterval = msecs_to_jiffies ( sp - > hbinterval ) ;
2021-06-22 21:04:48 +03:00
asoc - > probe_interval = msecs_to_jiffies ( sp - > probe_interval ) ;
2005-12-22 22:36:46 +03:00
2020-10-29 10:05:01 +03:00
asoc - > encap_port = sp - > encap_port ;
2005-12-22 22:36:46 +03:00
/* Initialize path max retrans value. */
asoc - > pathmaxrxt = sp - > pathmaxrxt ;
2018-07-02 13:21:12 +03:00
asoc - > flowlabel = sp - > flowlabel ;
asoc - > dscp = sp - > dscp ;
2005-12-22 22:36:46 +03:00
/* Set association default SACK delay */
asoc - > sackdelay = msecs_to_jiffies ( sp - > sackdelay ) ;
2008-05-10 02:13:26 +04:00
asoc - > sackfreq = sp - > sackfreq ;
2005-12-22 22:36:46 +03:00
/* Set the association default flags controlling
* Heartbeat , SACK delay , and Path MTU Discovery .
*/
asoc - > param_flags = sp - > param_flags ;
2013-12-06 05:36:30 +04:00
/* Initialize the maximum number of new data packets that can be sent
2005-04-17 02:20:36 +04:00
* in a burst .
*/
2007-03-23 21:34:36 +03:00
asoc - > max_burst = sp - > max_burst ;
2005-04-17 02:20:36 +04:00
2018-11-18 11:08:52 +03:00
asoc - > subscribe = sp - > subscribe ;
2005-11-12 03:06:16 +03: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 17:25:18 +03:00
asoc - > timeouts [ SCTP_EVENT_TIMEOUT_T5_SHUTDOWN_GUARD ]
2005-11-12 03:06:16 +03:00
= 5 * asoc - > rto_max ;
2005-12-22 22:36:46 +03:00
asoc - > timeouts [ SCTP_EVENT_TIMEOUT_SACK ] = asoc - > sackdelay ;
2013-12-10 15:48:15 +04:00
asoc - > timeouts [ SCTP_EVENT_TIMEOUT_AUTOCLOSE ] = sp - > autoclose * HZ ;
2007-02-09 17:25:18 +03:00
2010-06-11 14:17:00 +04:00
/* Initializes the timers */
2008-01-24 08:20:07 +03:00
for ( i = SCTP_EVENT_TIMEOUT_NONE ; i < SCTP_NUM_TIMEOUT_TYPES ; + + i )
2017-10-24 11:45:31 +03:00
timer_setup ( & asoc - > timers [ i ] , sctp_timer_events [ i ] , 0 ) ;
2005-04-17 02:20:36 +04: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 03:08:24 +03:00
if ( ( sk - > sk_rcvbuf / 2 ) < SCTP_DEFAULT_MINWINDOW )
2005-04-17 02:20:36 +04:00
asoc - > rwnd = SCTP_DEFAULT_MINWINDOW ;
else
2005-11-12 03:08:24 +03:00
asoc - > rwnd = sk - > sk_rcvbuf / 2 ;
2005-04-17 02:20:36 +04: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 03:08:24 +03:00
/* Initialize the receive memory counter */
atomic_set ( & asoc - > rmem_alloc , 0 ) ;
2005-04-17 02:20:36 +04: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 ;
2017-01-17 19:44:42 +03:00
asoc - > strreset_outseq = asoc - > c . initial_tsn ;
2005-04-17 02:20:36 +04:00
2005-07-09 08:47:49 +04:00
INIT_LIST_HEAD ( & asoc - > addip_chunk_list ) ;
2007-12-21 01:11:47 +03:00
INIT_LIST_HEAD ( & asoc - > asconf_ack_list ) ;
2005-04-17 02:20:36 +04: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 07:04:26 +04:00
asoc - > peer . sack_generation = 1 ;
2005-04-17 02:20:36 +04:00
/* Create an input queue. */
sctp_inq_init ( & asoc - > base . inqueue ) ;
2006-11-22 17:57:56 +03:00
sctp_inq_set_th_handler ( & asoc - > base . inqueue , sctp_assoc_bh_rcv ) ;
2005-04-17 02:20:36 +04:00
/* Create an output queue. */
sctp_outq_init ( asoc , & asoc - > outqueue ) ;
2022-10-19 21:07:33 +03:00
sctp_ulpq_init ( & asoc - > ulpq , asoc ) ;
2005-04-17 02:20:36 +04:00
2022-07-26 01:11:06 +03:00
if ( sctp_stream_init ( & asoc - > stream , asoc - > c . sinit_num_ostreams , 0 , gfp ) )
goto stream_free ;
2017-03-29 20:00:53 +03:00
2018-11-27 14:11:50 +03:00
/* Initialize default path MTU. */
asoc - > pathmtu = sp - > pathmtu ;
sctp_assoc_update_frag_point ( asoc ) ;
2005-04-17 02:20:36 +04:00
/* Assume that peer would support both address types unless we are
* told otherwise .
*/
asoc - > peer . ipv4_address = 1 ;
2009-04-07 12:35:11 +04:00
if ( asoc - > base . sk - > sk_family = = PF_INET6 )
asoc - > peer . ipv6_address = 1 ;
2005-04-17 02:20:36 +04: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 03:34:22 +03:00
asoc - > default_rcv_context = sp - > default_rcv_context ;
2005-04-17 02:20:36 +04:00
2007-09-17 06:31:35 +04:00
/* AUTH related initializations */
INIT_LIST_HEAD ( & asoc - > endpoint_shared_keys ) ;
2017-03-20 13:00:28 +03:00
if ( sctp_auth_asoc_copy_shkeys ( ep , asoc , gfp ) )
2017-03-29 20:00:53 +03:00
goto stream_free ;
2007-09-17 06:31:35 +04:00
asoc - > active_key_id = ep - > active_key_id ;
2017-01-17 19:44:46 +03:00
asoc - > strreset_enable = ep - > strreset_enable ;
2007-09-17 06:31:35 +04:00
/* 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 */
2017-06-30 06:52:16 +03:00
p = ( struct sctp_paramhdr * ) asoc - > c . auth_random ;
2007-09-17 06:31:35 +04:00
p - > type = SCTP_PARAM_RANDOM ;
2017-06-30 06:52:16 +03:00
p - > length = htons ( sizeof ( * p ) + SCTP_AUTH_RANDOM_LENGTH ) ;
2007-09-17 06:31:35 +04:00
get_random_bytes ( p + 1 , SCTP_AUTH_RANDOM_LENGTH ) ;
2005-04-17 02:20:36 +04:00
return asoc ;
2017-03-29 20:00:53 +03:00
stream_free :
2017-05-31 11:36:31 +03:00
sctp_stream_free ( & asoc - > stream ) ;
2005-04-17 02:20:36 +04:00
sock_put ( asoc - > base . sk ) ;
2013-06-14 20:24:07 +04:00
sctp_endpoint_put ( asoc - > ep ) ;
2005-04-17 02:20:36 +04:00
return NULL ;
}
/* Allocate and initialize a new association */
struct sctp_association * sctp_association_new ( const struct sctp_endpoint * ep ,
2017-08-05 14:59:54 +03:00
const struct sock * sk ,
enum sctp_scope scope , gfp_t gfp )
2005-04-17 02:20:36 +04:00
{
struct sctp_association * asoc ;
2013-06-17 13:40:04 +04:00
asoc = kzalloc ( sizeof ( * asoc ) , gfp ) ;
2005-04-17 02:20:36 +04: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 21:49:40 +04:00
pr_debug ( " Created asoc %p \n " , asoc ) ;
2005-04-17 02:20:36 +04: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 05:55:11 +03: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 06:53:36 +04:00
if ( ! list_empty ( & asoc - > asocs ) ) {
2006-10-31 05:55:11 +03:00
list_del ( & asoc - > asocs ) ;
/* Decrement the backlog value for a TCP-style listening
* socket .
*/
if ( sctp_style ( sk , TCP ) & & sctp_sstate ( sk , LISTENING ) )
2019-11-06 01:11:52 +03:00
sk_acceptq_removed ( sk ) ;
2006-10-31 05:55:11 +03:00
}
2005-04-17 02:20:36 +04:00
/* Mark as dead, so other users can know this structure is
* going away .
*/
2013-04-15 07:27:18 +04:00
asoc - > base . dead = true ;
2005-04-17 02:20:36 +04: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-09 01:18:39 +04:00
sctp_tsnmap_free ( & asoc - > peer . tsn_map ) ;
2017-01-06 17:18:33 +03:00
/* Free stream information. */
2017-05-31 11:36:31 +03:00
sctp_stream_free ( & asoc - > stream ) ;
2005-04-17 02:20:36 +04:00
2017-01-17 19:44:43 +03:00
if ( asoc - > strreset_chunk )
sctp_chunk_free ( asoc - > strreset_chunk ) ;
2005-04-17 02:20:36 +04:00
/* 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-04 00:32:57 +04:00
if ( del_timer ( & asoc - > timers [ i ] ) )
2005-04-17 02:20:36 +04:00
sctp_association_put ( asoc ) ;
}
/* Free peer's cached cookie. */
2005-11-08 20:41:34 +03:00
kfree ( asoc - > peer . cookie ) ;
2007-09-17 06:32:11 +04:00
kfree ( asoc - > peer . peer_random ) ;
kfree ( asoc - > peer . peer_chunks ) ;
kfree ( asoc - > peer . peer_hmacs ) ;
2005-04-17 02:20:36 +04: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 13:25:05 +04:00
list_del_rcu ( pos ) ;
2015-12-30 18:50:47 +03:00
sctp_unhash_transport ( transport ) ;
2005-04-17 02:20:36 +04:00
sctp_transport_free ( transport ) ;
}
2005-06-21 00:14:57 +04:00
asoc - > peer . transport_count = 0 ;
2011-05-30 03:23:36 +04:00
sctp_asconf_queue_teardown ( asoc ) ;
2005-04-17 02:20:36 +04:00
2011-04-26 15:19:36 +04:00
/* Free pending address space being deleted */
2015-01-31 20:10:03 +03:00
kfree ( asoc - > asconf_addr_del_pending ) ;
2011-04-26 15:19:36 +04:00
2007-09-17 06:31:35 +04: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-17 02:20:36 +04: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 21:49:40 +04:00
if ( unlikely ( ! asoc - > base . dead ) ) {
WARN ( 1 , " Attempt to destroy undead association %p! \n " , asoc ) ;
return ;
}
2005-04-17 02:20:36 +04: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 08:43:18 +04:00
WARN_ON ( atomic_read ( & asoc - > rmem_alloc ) ) ;
2005-11-12 03:08:24 +03:00
2018-11-30 20:36:59 +03:00
kfree_rcu ( asoc , rcu ) ;
2013-04-15 07:27:17 +04:00
SCTP_DBG_OBJCNT_DEC ( assoc ) ;
2005-04-17 02:20:36 +04: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 04:00:29 +04: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-17 02:20:36 +04:00
asoc - > peer . primary_path = transport ;
2020-05-27 12:59:43 +03:00
sctp_ulpevent_notify_peer_addr_change ( transport ,
2019-10-08 14:27:35 +03:00
SCTP_ADDR_MADE_PRIM , 0 ) ;
2005-04-17 02:20:36 +04:00
/* 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-22 01:48:50 +04:00
if ( ( transport - > state = = SCTP_ACTIVE ) | |
( transport - > state = = SCTP_UNKNOWN ) )
2005-04-17 02:20:36 +04: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 23:53:57 +03:00
*
* Really , only bother is we have data queued or outstanding on
* the association .
2005-04-17 02:20:36 +04:00
*/
2009-11-23 23:53:57 +03:00
if ( ! asoc - > outqueue . outstanding_bytes & & ! asoc - > outqueue . out_qlen )
return ;
2005-04-17 02:20:36 +04:00
if ( transport - > cacc . changeover_active )
2008-06-17 04:00:29 +04:00
transport - > cacc . cycling_changeover = changeover ;
2005-04-17 02:20:36 +04:00
/* 2) The sender MUST set CHANGEOVER_ACTIVE to indicate that
* a changeover has occurred .
*/
2008-06-17 04:00:29 +04:00
transport - > cacc . changeover_active = changeover ;
2005-04-17 02:20:36 +04: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-21 00:14:57 +04:00
/* Remove a transport from an association. */
void sctp_assoc_rm_peer ( struct sctp_association * asoc ,
struct sctp_transport * peer )
{
2018-10-29 18:10:29 +03:00
struct sctp_transport * transport ;
struct list_head * pos ;
struct sctp_chunk * ch ;
2005-06-21 00:14:57 +04: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 21:49:40 +04:00
pr_debug ( " %s: association:%p addr:%pISpc \n " ,
__func__ , asoc , & peer - > ipaddr . sa ) ;
2005-06-21 00:14:57 +04: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 13:25:05 +04:00
list_del_rcu ( & peer - > transports ) ;
2015-12-30 18:50:47 +03:00
/* Remove this peer from the transport hashtable */
sctp_unhash_transport ( peer ) ;
2005-06-21 00:14:57 +04: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 19:22:22 +04:00
if ( asoc - > peer . retran_path = = peer )
asoc - > peer . retran_path = transport ;
2005-06-21 00:14:57 +04:00
if ( asoc - > peer . last_data_from = = peer )
asoc - > peer . last_data_from = transport ;
2017-01-17 19:44:43 +03:00
if ( asoc - > strreset_chunk & &
asoc - > strreset_chunk - > transport = = peer ) {
asoc - > strreset_chunk - > transport = transport ;
sctp_transport_reset_reconf_timer ( transport ) ;
}
2005-06-21 00:14:57 +04:00
/* 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 19:13:35 +04: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 19:14:42 +04: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-05 02:21:00 +04: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 ;
/* 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 12:06:30 +04:00
* retransmitted .
2009-09-05 02:21:00 +04:00
*/
if ( ! timer_pending ( & active - > T3_rtx_timer ) )
if ( ! mod_timer ( & active - > T3_rtx_timer ,
jiffies + active - > rto ) )
sctp_transport_hold ( active ) ;
}
2018-10-29 18:10:29 +03:00
list_for_each_entry ( ch , & asoc - > outqueue . out_chunk_list , list )
if ( ch - > transport = = peer )
ch - > transport = NULL ;
2005-06-21 00:14:57 +04:00
asoc - > peer . transport_count - - ;
2020-05-27 12:59:43 +03:00
sctp_ulpevent_notify_peer_addr_change ( peer , SCTP_ADDR_REMOVED , 0 ) ;
2005-06-21 00:14:57 +04:00
sctp_transport_free ( peer ) ;
}
2005-04-17 02:20:36 +04: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 10:46:04 +04:00
const gfp_t gfp ,
2005-06-21 00:14:57 +04:00
const int peer_state )
2005-04-17 02:20:36 +04: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 04:10:20 +03:00
port = ntohs ( addr - > v4 . sin_port ) ;
2005-04-17 02:20:36 +04: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 21:49:40 +04:00
pr_debug ( " %s: association:%p addr:%pISpc state:%d \n " , __func__ ,
asoc , & addr - > sa , peer_state ) ;
2005-06-21 00:14:57 +04:00
2005-04-17 02:20:36 +04: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-21 00:14:57 +04:00
if ( peer ) {
2008-09-19 03:28:27 +04: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-22 01:48:50 +04:00
if ( peer - > state = = SCTP_UNKNOWN ) {
2008-09-19 03:28:27 +04:00
peer - > state = SCTP_ACTIVE ;
2006-07-22 01:48:50 +04:00
}
2005-04-17 02:20:36 +04:00
return peer ;
2005-06-21 00:14:57 +04:00
}
2005-04-17 02:20:36 +04:00
2019-12-09 08:45:18 +03:00
peer = sctp_transport_new ( asoc - > base . net , addr , gfp ) ;
2005-04-17 02:20:36 +04:00
if ( ! peer )
return NULL ;
sctp_transport_set_owner ( peer , asoc ) ;
2005-12-22 22:36:46 +03:00
/* Initialize the peer's heartbeat interval based on the
* association configured value .
*/
peer - > hbinterval = asoc - > hbinterval ;
2021-06-22 21:04:48 +03:00
peer - > probe_interval = asoc - > probe_interval ;
2005-12-22 22:36:46 +03:00
2020-10-29 10:05:01 +03:00
peer - > encap_port = asoc - > encap_port ;
2005-12-22 22:36:46 +03:00
/* Set the path max_retrans. */
peer - > pathmaxrxt = asoc - > pathmaxrxt ;
2013-10-26 12:06:30 +04:00
/* And the partial failure retrans threshold */
2012-07-21 11:56:07 +04:00
peer - > pf_retrans = asoc - > pf_retrans ;
2019-11-08 08:20:35 +03:00
/* And the primary path switchover retrans threshold */
peer - > ps_retrans = asoc - > ps_retrans ;
2012-07-21 11:56:07 +04:00
2005-12-22 22:36:46 +03:00
/* Initialize the peer's SACK delay timeout based on the
* association configured value .
*/
peer - > sackdelay = asoc - > sackdelay ;
2008-05-10 02:13:26 +04:00
peer - > sackfreq = asoc - > sackfreq ;
2005-12-22 22:36:46 +03:00
2018-07-02 13:21:14 +03:00
if ( addr - > sa . sa_family = = AF_INET6 ) {
__be32 info = addr - > v6 . sin6_flowinfo ;
if ( info ) {
peer - > flowlabel = ntohl ( info & IPV6_FLOWLABEL_MASK ) ;
peer - > flowlabel | = SCTP_FLOWLABEL_SET_MASK ;
} else {
peer - > flowlabel = asoc - > flowlabel ;
}
}
2018-07-02 13:21:12 +03:00
peer - > dscp = asoc - > dscp ;
2005-12-22 22:36:46 +03:00
/* Enable/disable heartbeat, SACK delay, and path MTU discovery
* based on association setting .
*/
peer - > param_flags = asoc - > param_flags ;
2005-04-17 02:20:36 +04:00
/* Initialize the pmtu of the transport. */
2018-04-26 22:58:51 +03:00
sctp_transport_route ( peer , NULL , sp ) ;
2005-04-17 02:20:36 +04: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 .
*/
2018-04-26 22:58:53 +03:00
sctp_assoc_set_pmtu ( asoc , asoc - > pathmtu ?
min_t ( int , peer - > pathmtu , asoc - > pathmtu ) :
peer - > pathmtu ) ;
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 21:49:40 +04:00
2008-07-19 10:04:39 +04:00
peer - > pmtu_pending = 0 ;
2005-04-17 02:20:36 +04: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 22:36:46 +03:00
peer - > cwnd = min ( 4 * asoc - > pathmtu , max_t ( __u32 , 2 * asoc - > pathmtu , 4380 ) ) ;
2005-04-17 02:20:36 +04: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 23:54:00 +03:00
peer - > burst_limited = 0 ;
2005-04-17 02:20:36 +04:00
/* Set the transport's RTO.initial value */
peer - > rto = asoc - > rto_initial ;
2012-12-01 08:49:42 +04:00
sctp_max_rto ( asoc , peer ) ;
2005-04-17 02:20:36 +04:00
2005-06-21 00:14:57 +04:00
/* Set the peer's active state. */
peer - > state = peer_state ;
2016-11-15 18:23:11 +03:00
/* Add this peer into the transport hashtable */
if ( sctp_hash_transport ( peer ) ) {
sctp_transport_free ( peer ) ;
return NULL ;
}
2021-06-22 21:04:56 +03:00
sctp_transport_pl_reset ( peer ) ;
2005-04-17 02:20:36 +04:00
/* Attach the remote transport to our asoc. */
2012-12-06 13:25:05 +04:00
list_add_tail_rcu ( & peer - > transports , & asoc - > peer . transport_addr_list ) ;
2005-06-21 00:14:57 +04:00
asoc - > peer . transport_count + + ;
2005-04-17 02:20:36 +04:00
2020-05-27 12:59:43 +03:00
sctp_ulpevent_notify_peer_addr_change ( peer , SCTP_ADDR_ADDED , 0 ) ;
2019-10-08 14:27:33 +03:00
2005-04-17 02:20:36 +04: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 06:39:26 +04:00
if ( asoc - > peer . active_path = = asoc - > peer . retran_path & &
peer - > state ! = SCTP_UNCONFIRMED ) {
2005-04-17 02:20:36 +04:00
asoc - > peer . retran_path = peer ;
2005-06-21 00:14:57 +04:00
}
2005-04-17 02:20:36 +04: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-21 00:14:57 +04:00
/* Do book keeping for removing the peer and free it. */
sctp_assoc_rm_peer ( asoc , transport ) ;
2005-04-17 02:20:36 +04: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 05:54:24 +04:00
list_for_each_entry ( t , & asoc - > peer . transport_addr_list ,
transports ) {
2005-04-17 02:20:36 +04:00
if ( sctp_cmp_addr_exact ( address , & t - > ipaddr ) )
return t ;
}
return NULL ;
}
2007-12-21 01:08:56 +03: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-17 02:20:36 +04: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 ,
2017-08-05 14:59:55 +03:00
enum sctp_transport_cmd command ,
2005-04-17 02:20:36 +04:00
sctp_sn_error_t error )
{
sctp: add SCTP_ADDR_POTENTIALLY_FAILED notification
SCTP Quick failover draft section 5.1, point 5 has been removed
from rfc7829. Instead, "the sender SHOULD (i) notify the Upper
Layer Protocol (ULP) about this state transition", as said in
section 3.2, point 8.
So this patch is to add SCTP_ADDR_POTENTIALLY_FAILED, defined
in section 7.1, "which is reported if the affected address
becomes PF". Also remove transport cwnd's update when moving
from PF back to ACTIVE , which is no longer in rfc7829 either.
Note that ulp_notify will be set to false if asoc->expose is
not 'enabled', according to last patch.
v2->v3:
- define SCTP_ADDR_PF SCTP_ADDR_POTENTIALLY_FAILED.
v3->v4:
- initialize spc_state with SCTP_ADDR_AVAILABLE, as Marcelo suggested.
- check asoc->pf_expose in sctp_assoc_control_transport(), as Marcelo
suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 08:20:33 +03:00
int spc_state = SCTP_ADDR_AVAILABLE ;
2012-07-21 11:56:07 +04:00
bool ulp_notify = true ;
2005-04-17 02:20:36 +04:00
/* Record the transition on the transport. */
switch ( command ) {
case SCTP_TRANSPORT_UP :
2007-03-23 21:32:26 +03: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 .
*/
sctp: add SCTP_ADDR_POTENTIALLY_FAILED notification
SCTP Quick failover draft section 5.1, point 5 has been removed
from rfc7829. Instead, "the sender SHOULD (i) notify the Upper
Layer Protocol (ULP) about this state transition", as said in
section 3.2, point 8.
So this patch is to add SCTP_ADDR_POTENTIALLY_FAILED, defined
in section 7.1, "which is reported if the affected address
becomes PF". Also remove transport cwnd's update when moving
from PF back to ACTIVE , which is no longer in rfc7829 either.
Note that ulp_notify will be set to false if asoc->expose is
not 'enabled', according to last patch.
v2->v3:
- define SCTP_ADDR_PF SCTP_ADDR_POTENTIALLY_FAILED.
v3->v4:
- initialize spc_state with SCTP_ADDR_AVAILABLE, as Marcelo suggested.
- check asoc->pf_expose in sctp_assoc_control_transport(), as Marcelo
suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 08:20:33 +03:00
if ( transport - > state = = SCTP_PF & &
asoc - > pf_expose ! = SCTP_PF_EXPOSE_ENABLE )
2012-07-21 11:56:07 +04:00
ulp_notify = false ;
sctp: add SCTP_ADDR_POTENTIALLY_FAILED notification
SCTP Quick failover draft section 5.1, point 5 has been removed
from rfc7829. Instead, "the sender SHOULD (i) notify the Upper
Layer Protocol (ULP) about this state transition", as said in
section 3.2, point 8.
So this patch is to add SCTP_ADDR_POTENTIALLY_FAILED, defined
in section 7.1, "which is reported if the affected address
becomes PF". Also remove transport cwnd's update when moving
from PF back to ACTIVE , which is no longer in rfc7829 either.
Note that ulp_notify will be set to false if asoc->expose is
not 'enabled', according to last patch.
v2->v3:
- define SCTP_ADDR_PF SCTP_ADDR_POTENTIALLY_FAILED.
v3->v4:
- initialize spc_state with SCTP_ADDR_AVAILABLE, as Marcelo suggested.
- check asoc->pf_expose in sctp_assoc_control_transport(), as Marcelo
suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 08:20:33 +03:00
else if ( transport - > state = = SCTP_UNCONFIRMED & &
error = = SCTP_HEARTBEAT_SUCCESS )
spc_state = SCTP_ADDR_CONFIRMED ;
2005-06-21 00:14:57 +04:00
transport - > state = SCTP_ACTIVE ;
2021-06-22 21:04:56 +03:00
sctp_transport_pl_reset ( transport ) ;
2005-04-17 02:20:36 +04:00
break ;
case SCTP_TRANSPORT_DOWN :
2009-06-23 19:28:05 +04: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 14:30:25 +04:00
*/
sctp: add SCTP_ADDR_POTENTIALLY_FAILED notification
SCTP Quick failover draft section 5.1, point 5 has been removed
from rfc7829. Instead, "the sender SHOULD (i) notify the Upper
Layer Protocol (ULP) about this state transition", as said in
section 3.2, point 8.
So this patch is to add SCTP_ADDR_POTENTIALLY_FAILED, defined
in section 7.1, "which is reported if the affected address
becomes PF". Also remove transport cwnd's update when moving
from PF back to ACTIVE , which is no longer in rfc7829 either.
Note that ulp_notify will be set to false if asoc->expose is
not 'enabled', according to last patch.
v2->v3:
- define SCTP_ADDR_PF SCTP_ADDR_POTENTIALLY_FAILED.
v3->v4:
- initialize spc_state with SCTP_ADDR_AVAILABLE, as Marcelo suggested.
- check asoc->pf_expose in sctp_assoc_control_transport(), as Marcelo
suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 08:20:33 +03:00
if ( transport - > state ! = SCTP_UNCONFIRMED ) {
2007-08-24 14:30:25 +04:00
transport - > state = SCTP_INACTIVE ;
2021-06-22 21:04:56 +03:00
sctp_transport_pl_reset ( transport ) ;
sctp: add SCTP_ADDR_POTENTIALLY_FAILED notification
SCTP Quick failover draft section 5.1, point 5 has been removed
from rfc7829. Instead, "the sender SHOULD (i) notify the Upper
Layer Protocol (ULP) about this state transition", as said in
section 3.2, point 8.
So this patch is to add SCTP_ADDR_POTENTIALLY_FAILED, defined
in section 7.1, "which is reported if the affected address
becomes PF". Also remove transport cwnd's update when moving
from PF back to ACTIVE , which is no longer in rfc7829 either.
Note that ulp_notify will be set to false if asoc->expose is
not 'enabled', according to last patch.
v2->v3:
- define SCTP_ADDR_PF SCTP_ADDR_POTENTIALLY_FAILED.
v3->v4:
- initialize spc_state with SCTP_ADDR_AVAILABLE, as Marcelo suggested.
- check asoc->pf_expose in sctp_assoc_control_transport(), as Marcelo
suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 08:20:33 +03:00
spc_state = SCTP_ADDR_UNREACHABLE ;
} else {
2017-02-07 00:14:13 +03:00
sctp_transport_dst_release ( transport ) ;
2014-08-20 13:31:43 +04:00
ulp_notify = false ;
2009-06-23 19:28:05 +04:00
}
2005-04-17 02:20:36 +04:00
break ;
2012-07-21 11:56:07 +04:00
case SCTP_TRANSPORT_PF :
transport - > state = SCTP_PF ;
sctp: add SCTP_ADDR_POTENTIALLY_FAILED notification
SCTP Quick failover draft section 5.1, point 5 has been removed
from rfc7829. Instead, "the sender SHOULD (i) notify the Upper
Layer Protocol (ULP) about this state transition", as said in
section 3.2, point 8.
So this patch is to add SCTP_ADDR_POTENTIALLY_FAILED, defined
in section 7.1, "which is reported if the affected address
becomes PF". Also remove transport cwnd's update when moving
from PF back to ACTIVE , which is no longer in rfc7829 either.
Note that ulp_notify will be set to false if asoc->expose is
not 'enabled', according to last patch.
v2->v3:
- define SCTP_ADDR_PF SCTP_ADDR_POTENTIALLY_FAILED.
v3->v4:
- initialize spc_state with SCTP_ADDR_AVAILABLE, as Marcelo suggested.
- check asoc->pf_expose in sctp_assoc_control_transport(), as Marcelo
suggested.
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2019-11-08 08:20:33 +03:00
if ( asoc - > pf_expose ! = SCTP_PF_EXPOSE_ENABLE )
ulp_notify = false ;
else
spc_state = SCTP_ADDR_POTENTIALLY_FAILED ;
2012-07-21 11:56:07 +04:00
break ;
2005-04-17 02:20:36 +04:00
default :
return ;
2007-04-21 04:09:22 +04:00
}
2005-04-17 02:20:36 +04:00
2014-06-11 20:19:29 +04:00
/* Generate and send a SCTP_PEER_ADDR_CHANGE notification
* to the user .
2005-04-17 02:20:36 +04:00
*/
2019-10-08 14:27:33 +03:00
if ( ulp_notify )
2020-05-27 12:59:43 +03:00
sctp_ulpevent_notify_peer_addr_change ( transport ,
2019-10-08 14:27:33 +03:00
spc_state , error ) ;
2005-04-17 02:20:36 +04:00
/* Select new active and retran paths. */
2014-06-11 20:19:29 +04:00
sctp_select_active_and_retran_path ( asoc ) ;
2005-04-17 02:20:36 +04:00
}
/* Hold a reference to an association. */
void sctp_association_hold ( struct sctp_association * asoc )
{
2017-07-04 15:53:28 +03:00
refcount_inc ( & asoc - > base . refcnt ) ;
2005-04-17 02:20:36 +04:00
}
/* Release a reference to an association and cleanup
* if there are no more references .
*/
void sctp_association_put ( struct sctp_association * asoc )
{
2017-07-04 15:53:28 +03:00
if ( refcount_dec_and_test ( & asoc - > base . refcnt ) )
2005-04-17 02:20:36 +04:00
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 05:36:28 +04:00
if ( ! asoc - > need_ecne )
return NULL ;
2005-04-17 02:20:36 +04:00
/* Send ECNE if needed.
* Not being able to allocate a chunk here is not deadly .
*/
2013-12-06 05:36:28 +04:00
return sctp_make_ecne ( asoc , asoc - > last_ecne_tsn ) ;
2005-04-17 02:20:36 +04: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 04:01:42 +03:00
__be32 key = htonl ( tsn ) ;
2005-04-17 02:20:36 +04: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 05:54:24 +04:00
list_for_each_entry ( chunk , & active - > transmitted ,
transmitted_list ) {
2005-04-17 02:20:36 +04:00
if ( key = = chunk - > subh . data_hdr - > tsn ) {
match = active ;
goto out ;
}
}
/* If not found, go search all the other transports. */
2008-04-13 05:54:24 +04:00
list_for_each_entry ( transport , & asoc - > peer . transport_addr_list ,
transports ) {
2005-04-17 02:20:36 +04:00
if ( transport = = active )
2013-03-08 01:39:37 +04:00
continue ;
2008-04-13 05:54:24 +04:00
list_for_each_entry ( chunk , & transport - > transmitted ,
transmitted_list ) {
2005-04-17 02:20:36 +04:00
if ( key = = chunk - > subh . data_hdr - > tsn ) {
match = transport ;
goto out ;
}
}
}
out :
return match ;
}
/* Do delayed input processing. This is scheduled by sctp_rcv(). */
2006-11-22 17:57:56 +03:00
static void sctp_assoc_bh_rcv ( struct work_struct * work )
2005-04-17 02:20:36 +04:00
{
2006-11-22 17:57:56 +03:00
struct sctp_association * asoc =
container_of ( work , struct sctp_association ,
base . inqueue . immediate ) ;
2019-12-09 08:45:18 +03:00
struct net * net = asoc - > base . net ;
2017-08-05 15:00:04 +03:00
union sctp_subtype subtype ;
2005-04-17 02:20:36 +04:00
struct sctp_endpoint * ep ;
struct sctp_chunk * chunk ;
struct sctp_inq * inqueue ;
2018-05-05 09:59:47 +03:00
int first_time = 1 ; /* is this the first time through the loop */
2005-04-17 02:20:36 +04:00
int error = 0 ;
2018-05-05 09:59:47 +03:00
int state ;
2005-04-17 02:20:36 +04:00
/* 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 ) ;
2018-05-05 09:59:47 +03:00
/* If the first chunk in the packet is AUTH, do special
* processing specified in Section 6.3 of SCTP - AUTH spec
*/
if ( first_time & & subtype . chunk = = SCTP_CID_AUTH ) {
struct sctp_chunkhdr * next_hdr ;
next_hdr = sctp_inq_peek ( inqueue ) ;
if ( ! next_hdr )
goto normal ;
/* If the next chunk is COOKIE-ECHO, skip the AUTH
* chunk while saving a pointer to it so we can do
* Authentication later ( during cookie - echo
* processing ) .
*/
if ( next_hdr - > type = = SCTP_CID_COOKIE_ECHO ) {
chunk - > auth_chunk = skb_clone ( chunk - > skb ,
GFP_ATOMIC ) ;
chunk - > auth = 1 ;
continue ;
}
}
normal :
2007-10-04 04:51:34 +04: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-17 02:20:36 +04: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 08:49:42 +04:00
else {
2012-08-07 11:25:24 +04:00
SCTP_INC_STATS ( net , SCTP_MIB_INCTRLCHUNKS ) ;
2012-12-01 08:49:42 +04:00
asoc - > stats . ictrlchunks + + ;
if ( chunk - > chunk_hdr - > type = = SCTP_CID_SACK )
asoc - > stats . isacks + + ;
}
2005-04-17 02:20:36 +04:00
if ( chunk - > transport )
2014-06-11 20:19:30 +04:00
chunk - > transport - > last_time_heard = ktime_get ( ) ;
2005-04-17 02:20:36 +04:00
/* Run through the state machine. */
2012-08-07 11:25:24 +04:00
error = sctp_do_sm ( net , SCTP_EVENT_T_CHUNK , subtype ,
2005-04-17 02:20:36 +04: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 ;
2018-05-05 09:59:47 +03:00
if ( first_time )
first_time = 0 ;
2005-04-17 02:20:36 +04:00
}
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 ) )
2019-11-06 01:11:52 +03:00
sk_acceptq_removed ( oldsk ) ;
2005-04-17 02:20:36 +04:00
/* 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). */
2017-06-20 11:05:11 +03:00
int sctp_assoc_update ( struct sctp_association * asoc ,
struct sctp_association * new )
2005-04-17 02:20:36 +04:00
{
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 ;
net: sctp: inherit auth_capable on INIT collisions
Jason reported an oops caused by SCTP on his ARM machine with
SCTP authentication enabled:
Internal error: Oops: 17 [#1] ARM
CPU: 0 PID: 104 Comm: sctp-test Not tainted 3.13.0-68744-g3632f30c9b20-dirty #1
task: c6eefa40 ti: c6f52000 task.ti: c6f52000
PC is at sctp_auth_calculate_hmac+0xc4/0x10c
LR is at sg_init_table+0x20/0x38
pc : [<c024bb80>] lr : [<c00f32dc>] psr: 40000013
sp : c6f538e8 ip : 00000000 fp : c6f53924
r10: c6f50d80 r9 : 00000000 r8 : 00010000
r7 : 00000000 r6 : c7be4000 r5 : 00000000 r4 : c6f56254
r3 : c00c8170 r2 : 00000001 r1 : 00000008 r0 : c6f1e660
Flags: nZcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
Control: 0005397f Table: 06f28000 DAC: 00000015
Process sctp-test (pid: 104, stack limit = 0xc6f521c0)
Stack: (0xc6f538e8 to 0xc6f54000)
[...]
Backtrace:
[<c024babc>] (sctp_auth_calculate_hmac+0x0/0x10c) from [<c0249af8>] (sctp_packet_transmit+0x33c/0x5c8)
[<c02497bc>] (sctp_packet_transmit+0x0/0x5c8) from [<c023e96c>] (sctp_outq_flush+0x7fc/0x844)
[<c023e170>] (sctp_outq_flush+0x0/0x844) from [<c023ef78>] (sctp_outq_uncork+0x24/0x28)
[<c023ef54>] (sctp_outq_uncork+0x0/0x28) from [<c0234364>] (sctp_side_effects+0x1134/0x1220)
[<c0233230>] (sctp_side_effects+0x0/0x1220) from [<c02330b0>] (sctp_do_sm+0xac/0xd4)
[<c0233004>] (sctp_do_sm+0x0/0xd4) from [<c023675c>] (sctp_assoc_bh_rcv+0x118/0x160)
[<c0236644>] (sctp_assoc_bh_rcv+0x0/0x160) from [<c023d5bc>] (sctp_inq_push+0x6c/0x74)
[<c023d550>] (sctp_inq_push+0x0/0x74) from [<c024a6b0>] (sctp_rcv+0x7d8/0x888)
While we already had various kind of bugs in that area
ec0223ec48a9 ("net: sctp: fix sctp_sf_do_5_1D_ce to verify if
we/peer is AUTH capable") and b14878ccb7fa ("net: sctp: cache
auth_enable per endpoint"), this one is a bit of a different
kind.
Giving a bit more background on why SCTP authentication is
needed can be found in RFC4895:
SCTP uses 32-bit verification tags to protect itself against
blind attackers. These values are not changed during the
lifetime of an SCTP association.
Looking at new SCTP extensions, there is the need to have a
method of proving that an SCTP chunk(s) was really sent by
the original peer that started the association and not by a
malicious attacker.
To cause this bug, we're triggering an INIT collision between
peers; normal SCTP handshake where both sides intent to
authenticate packets contains RANDOM; CHUNKS; HMAC-ALGO
parameters that are being negotiated among peers:
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
<------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
-------------------- COOKIE-ECHO -------------------->
<-------------------- COOKIE-ACK ---------------------
RFC4895 says that each endpoint therefore knows its own random
number and the peer's random number *after* the association
has been established. The local and peer's random number along
with the shared key are then part of the secret used for
calculating the HMAC in the AUTH chunk.
Now, in our scenario, we have 2 threads with 1 non-blocking
SEQ_PACKET socket each, setting up common shared SCTP_AUTH_KEY
and SCTP_AUTH_ACTIVE_KEY properly, and each of them calling
sctp_bindx(3), listen(2) and connect(2) against each other,
thus the handshake looks similar to this, e.g.:
---------- INIT[RANDOM; CHUNKS; HMAC-ALGO] ---------->
<------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] ---------
<--------- INIT[RANDOM; CHUNKS; HMAC-ALGO] -----------
-------- INIT-ACK[RANDOM; CHUNKS; HMAC-ALGO] -------->
...
Since such collisions can also happen with verification tags,
the RFC4895 for AUTH rather vaguely says under section 6.1:
In case of INIT collision, the rules governing the handling
of this Random Number follow the same pattern as those for
the Verification Tag, as explained in Section 5.2.4 of
RFC 2960 [5]. Therefore, each endpoint knows its own Random
Number and the peer's Random Number after the association
has been established.
In RFC2960, section 5.2.4, we're eventually hitting Action B:
B) In this case, both sides may be attempting to start an
association at about the same time but the peer endpoint
started its INIT after responding to the local endpoint's
INIT. Thus it may have picked a new Verification Tag not
being aware of the previous Tag it had sent this endpoint.
The endpoint should stay in or enter the ESTABLISHED
state but it MUST update its peer's Verification Tag from
the State Cookie, stop any init or cookie timers that may
running and send a COOKIE ACK.
In other words, the handling of the Random parameter is the
same as behavior for the Verification Tag as described in
Action B of section 5.2.4.
Looking at the code, we exactly hit the sctp_sf_do_dupcook_b()
case which triggers an SCTP_CMD_UPDATE_ASSOC command to the
side effect interpreter, and in fact it properly copies over
peer_{random, hmacs, chunks} parameters from the newly created
association to update the existing one.
Also, the old asoc_shared_key is being released and based on
the new params, sctp_auth_asoc_init_active_key() updated.
However, the issue observed in this case is that the previous
asoc->peer.auth_capable was 0, and has *not* been updated, so
that instead of creating a new secret, we're doing an early
return from the function sctp_auth_asoc_init_active_key()
leaving asoc->asoc_shared_key as NULL. However, we now have to
authenticate chunks from the updated chunk list (e.g. COOKIE-ACK).
That in fact causes the server side when responding with ...
<------------------ AUTH; COOKIE-ACK -----------------
... to trigger a NULL pointer dereference, since in
sctp_packet_transmit(), it discovers that an AUTH chunk is
being queued for xmit, and thus it calls sctp_auth_calculate_hmac().
Since the asoc->active_key_id is still inherited from the
endpoint, and the same as encoded into the chunk, it uses
asoc->asoc_shared_key, which is still NULL, as an asoc_key
and dereferences it in ...
crypto_hash_setkey(desc.tfm, &asoc_key->data[0], asoc_key->len)
... causing an oops. All this happens because sctp_make_cookie_ack()
called with the *new* association has the peer.auth_capable=1
and therefore marks the chunk with auth=1 after checking
sctp_auth_send_cid(), but it is *actually* sent later on over
the then *updated* association's transport that didn't initialize
its shared key due to peer.auth_capable=0. Since control chunks
in that case are not sent by the temporary association which
are scheduled for deletion, they are issued for xmit via
SCTP_CMD_REPLY in the interpreter with the context of the
*updated* association. peer.auth_capable was 0 in the updated
association (which went from COOKIE_WAIT into ESTABLISHED state),
since all previous processing that performed sctp_process_init()
was being done on temporary associations, that we eventually
throw away each time.
The correct fix is to update to the new peer.auth_capable
value as well in the collision case via sctp_assoc_update(),
so that in case the collision migrated from 0 -> 1,
sctp_auth_asoc_init_active_key() can properly recalculate
the secret. This therefore fixes the observed server panic.
Fixes: 730fc3d05cd4 ("[SCTP]: Implete SCTP-AUTH parameter processing")
Reported-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Tested-by: Jason Gunthorpe <jgunthorpe@obsidianresearch.com>
Cc: Vlad Yasevich <vyasevich@gmail.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-07-22 17:22:45 +04:00
asoc - > peer . auth_capable = new - > peer . auth_capable ;
2005-04-17 02:20:36 +04:00
asoc - > peer . i = new - > peer . i ;
2017-06-20 11:05:11 +03:00
if ( ! sctp_tsnmap_init ( & asoc - > peer . tsn_map , SCTP_TSN_MAP_INITIAL ,
asoc - > peer . i . initial_tsn , GFP_ATOMIC ) )
return - ENOMEM ;
2005-04-17 02:20:36 +04: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 12:47:19 +04:00
if ( ! sctp_assoc_lookup_paddr ( new , & trans - > ipaddr ) ) {
sctp_assoc_rm_peer ( asoc , trans ) ;
continue ;
}
2007-03-20 03:02:30 +03:00
if ( asoc - > state > = SCTP_STATE_ESTABLISHED )
sctp_transport_reset ( trans ) ;
2005-04-17 02:20:36 +04: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 .
*/
2017-05-31 11:36:31 +03:00
sctp_stream_clear ( & asoc - > stream ) ;
2005-04-17 02:20:36 +04:00
2007-03-20 03:01:17 +03: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 03:02:30 +03: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-17 02:20:36 +04:00
} else {
/* Add any peer addresses from the new association. */
2008-04-13 05:54:24 +04:00
list_for_each_entry ( trans , & new - > peer . transport_addr_list ,
2017-06-20 11:05:11 +03:00
transports )
2023-10-01 17:58:45 +03:00
if ( ! sctp_assoc_add_peer ( asoc , & trans - > ipaddr ,
2017-06-20 11:05:11 +03:00
GFP_ATOMIC , trans - > state ) )
return - ENOMEM ;
2005-04-17 02:20:36 +04:00
asoc - > ctsn_ack_point = asoc - > next_tsn - 1 ;
asoc - > adv_peer_ack_point = asoc - > ctsn_ack_point ;
2017-05-23 08:28:54 +03:00
2017-05-31 11:36:31 +03:00
if ( sctp_state ( asoc , COOKIE_WAIT ) )
sctp_stream_update ( & asoc - > stream , & new - > stream ) ;
2007-05-05 00:55:27 +04:00
2017-06-10 10:27:12 +03:00
/* get a new assoc id if we don't have one yet. */
2017-06-20 11:05:11 +03:00
if ( sctp_assoc_set_id ( asoc , GFP_ATOMIC ) )
return - ENOMEM ;
2005-04-17 02:20:36 +04:00
}
2007-09-17 06:31:35 +04:00
2013-12-06 05:36:30 +04:00
/* SCTP-AUTH: Save the peer parameters from the new associations
2007-09-17 06:32:11 +04: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 ;
2017-06-20 11:05:11 +03:00
return sctp_auth_asoc_init_active_key ( asoc , GFP_ATOMIC ) ;
2005-04-17 02:20:36 +04: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 23:51:06 +04: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
2015-09-28 15:34:04 +03:00
* according to sctp_trans_score ( ) e . g . , if no such
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 23:51:06 +04:00
* transport with state SCTP_ACTIVE exists , round - robin through
* SCTP_UNKNOWN , etc . You get the picture .
2005-04-17 02:20:36 +04: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 23:51:06 +04:00
static u8 sctp_trans_score ( const struct sctp_transport * trans )
2005-04-17 02:20:36 +04:00
{
2015-09-28 15:34:04 +03:00
switch ( trans - > state ) {
case SCTP_ACTIVE :
return 3 ; /* best case */
case SCTP_UNKNOWN :
return 2 ;
case SCTP_PF :
return 1 ;
default : /* case SCTP_INACTIVE */
return 0 ; /* worst case */
}
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 23:51:06 +04:00
}
2005-04-17 02:20:36 +04: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 20:19:31 +04: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 23:51:06 +04: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 20:19:31 +04:00
u8 score_curr , score_best ;
2014-08-22 15:03:29 +04:00
if ( best = = NULL | | curr = = 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 23:51:06 +04:00
return curr ;
2008-06-04 23:37:33 +04: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 20:19:31 +04: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 )
sctp: fix the transports round robin issue when init is retransmitted
prior to this patch, at the beginning if we have two paths in one assoc,
they may have the same params other than the last_time_heard, it will try
the paths like this:
1st cycle
try trans1 fail.
then trans2 is selected.(cause it's last_time_heard is after trans1).
2nd cycle:
try trans2 fail
then trans2 is selected.(cause it's last_time_heard is after trans1).
3rd cycle:
try trans2 fail
then trans2 is selected.(cause it's last_time_heard is after trans1).
....
trans1 will never have change to be selected, which is not what we expect.
we should keeping round robin all the paths if they are just added at the
beginning.
So at first every tranport's last_time_heard should be initialized 0, so
that we ensure they have the same value at the beginning, only by this,
all the transports could get equal chance to be selected.
Then for sctp_trans_elect_best, it should return the trans_next one when
*trans == *trans_next, so that we can try next if it fails, but now it
always return trans. so we can fix it by exchanging these two params when
we calls sctp_trans_elect_tie().
Fixes: 4c47af4d5eb2 ('net: sctp: rework multihoming retransmission path selection to rfc4960')
Signed-off-by: Xin Long <lucien.xin@gmail.com>
Acked-by: Daniel Borkmann <daniel@iogearbox.net>
Acked-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-03-10 10:31:57 +03:00
return sctp_trans_elect_tie ( best , curr ) ;
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 20:19:31 +04:00
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 23:51:06 +04:00
}
2005-04-17 02:20:36 +04: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 23:51:06 +04: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-17 02:20:36 +04: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 23:51:06 +04: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-17 02:20:36 +04: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 23:51:06 +04: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 23:37:33 +04: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 23:51:06 +04:00
/* We've reached the end, time to update path. */
if ( trans = = asoc - > peer . retran_path )
2005-04-17 02:20:36 +04: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 17:45:26 +04:00
asoc - > peer . retran_path = trans_next ;
2005-06-21 00:14:57 +04: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 23:51:06 +04:00
pr_debug ( " %s: association:%p updated new path to addr:%pISpc \n " ,
__func__ , asoc , & asoc - > peer . retran_path - > ipaddr . sa ) ;
2005-06-21 00:14:57 +04:00
}
2014-06-11 20:19:29 +04: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 20:19:31 +04:00
struct sctp_transport * trans_pf = NULL ;
2014-06-11 20:19:29 +04: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 20:19:31 +04:00
/* Skip uninteresting transports. */
2014-06-11 20:19:29 +04: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 20:19:31 +04:00
trans - > state = = SCTP_UNCONFIRMED )
2014-06-11 20:19:29 +04: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 20:19:31 +04: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 20:19:29 +04:00
if ( trans_pri = = NULL | |
2014-06-11 20:19:30 +04:00
ktime_after ( trans - > last_time_heard ,
trans_pri - > last_time_heard ) ) {
2014-06-11 20:19:29 +04:00
trans_sec = trans_pri ;
trans_pri = trans ;
} else if ( trans_sec = = NULL | |
2014-06-11 20:19:30 +04:00
ktime_after ( trans - > last_time_heard ,
trans_sec - > last_time_heard ) ) {
2014-06-11 20:19:29 +04: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
2020-08-23 02:15:55 +03:00
* path ; either primary path that we found is the same as
2014-06-11 20:19:29 +04:00
* 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: fix suboptimal edge-case on non-active active/retrans path selection
In SCTP, selection of active (T.ACT) and retransmission (T.RET)
transports is being done whenever transport control operations
(UP, DOWN, PF, ...) are engaged through sctp_assoc_control_transport().
Commits 4c47af4d5eb2 ("net: sctp: rework multihoming retransmission
path selection to rfc4960") and a7288c4dd509 ("net: sctp: improve
sctp_select_active_and_retran_path selection") have both improved
it towards a more fine-grained and optimal path selection.
Currently, the selection algorithm for T.ACT and T.RET is as follows:
1) Elect the two most recently used ACTIVE transports T1, T2 for
T.ACT, T.RET, where T.ACT<-T1 and T1 is most recently used
2) In case primary path T.PRI not in {T1, T2} but ACTIVE, set
T.ACT<-T.PRI and T.RET<-T1
3) If only T1 is ACTIVE from the set, set T.ACT<-T1 and T.RET<-T1
4) If none is ACTIVE, set T.ACT<-best(T.PRI, T.RET, T3) where
T3 is the most recently used (if avail) in PF, set T.RET<-T.PRI
Prior to above commits, 4) was simply a camp on T.ACT<-T.PRI and
T.RET<-T.PRI, ignoring possible paths in PF. Camping on T.PRI is
still slightly suboptimal as it can lead to the following scenario:
Setup:
<A> <B>
T1: p1p1 (10.0.10.10) <==> .'`) <==> p1p1 (10.0.10.12) <= T.PRI
T2: p1p2 (10.0.10.20) <==> (_ . ) <==> p1p2 (10.0.10.22)
net.sctp.rto_min = 1000
net.sctp.path_max_retrans = 2
net.sctp.pf_retrans = 0
net.sctp.hb_interval = 1000
T.PRI is permanently down, T2 is put briefly into PF state (e.g. due to
link flapping). Here, the first time transmission is sent over PF path
T2 as it's the only non-INACTIVE path, but the retransmitted data-chunks
are sent over the INACTIVE path T1 (T.PRI), which is not good.
After the patch, it's choosing better transports in both cases by
modifying step 4):
4) If none is ACTIVE, set T.ACT_new<-best(T.ACT_old, T3) where T3 is
the most recently used (if avail) in PF, set T.RET<-T.ACT_new
This will still select a best possible path in PF if available (which
can also include T.PRI/T.RET), and set both T.ACT/T.RET to it.
In case sctp_assoc_control_transport() *just* put T.ACT_old into INACTIVE
as it transitioned from ACTIVE->PF->INACTIVE and stays in INACTIVE just
for a very short while before going back ACTIVE, it will guarantee that
this path will be reselected for T.ACT/T.RET since T3 (PF) is not
available.
Previously, this was not possible, as we would only select between T.PRI
and T.RET, and a possible T3 would be NULL due to the fact that we have
just transitioned T3 in sctp_assoc_control_transport() from PF->INACTIVE
and would select a suboptimal path when T.PRI/T.RET have worse properties.
In the case that T.ACT_old permanently went to INACTIVE during this
transition and there's no PF path available, plus T.PRI and T.RET are
INACTIVE as well, we would now camp on T.ACT_old, but if everything is
being INACTIVE there's really not much we can do except hoping for a
successful HB to bring one of the transports back up again and, thus
cause a new selection through sctp_assoc_control_transport().
Now both tests work fine:
Case 1:
1. T1 S(ACTIVE) T.ACT
T2 S(ACTIVE) T.RET
2. T1 S(ACTIVE) T.ACT, T.RET
T2 S(PF)
3. T1 S(ACTIVE) T.ACT, T.RET
T2 S(INACTIVE)
5. T1 S(PF) T.ACT, T.RET
T2 S(INACTIVE)
[ 5.1 T1 S(INACTIVE) T.ACT, T.RET
T2 S(INACTIVE) ]
6. T1 S(ACTIVE) T.ACT, T.RET
T2 S(INACTIVE)
7. T1 S(ACTIVE) T.ACT
T2 S(ACTIVE) T.RET
Case 2:
1. T1 S(ACTIVE) T.ACT
T2 S(ACTIVE) T.RET
2. T1 S(PF)
T2 S(ACTIVE) T.ACT, T.RET
3. T1 S(INACTIVE)
T2 S(ACTIVE) T.ACT, T.RET
5. T1 S(INACTIVE)
T2 S(PF) T.ACT, T.RET
[ 5.1 T1 S(INACTIVE)
T2 S(INACTIVE) T.ACT, T.RET ]
6. T1 S(INACTIVE)
T2 S(ACTIVE) T.ACT, T.RET
7. T1 S(ACTIVE) T.ACT
T2 S(ACTIVE) T.RET
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-08-22 15:03:30 +04:00
* active or pick a PF iff it ' s the better choice .
2014-06-11 20:19:29 +04:00
*/
if ( trans_pri = = NULL ) {
net: sctp: fix suboptimal edge-case on non-active active/retrans path selection
In SCTP, selection of active (T.ACT) and retransmission (T.RET)
transports is being done whenever transport control operations
(UP, DOWN, PF, ...) are engaged through sctp_assoc_control_transport().
Commits 4c47af4d5eb2 ("net: sctp: rework multihoming retransmission
path selection to rfc4960") and a7288c4dd509 ("net: sctp: improve
sctp_select_active_and_retran_path selection") have both improved
it towards a more fine-grained and optimal path selection.
Currently, the selection algorithm for T.ACT and T.RET is as follows:
1) Elect the two most recently used ACTIVE transports T1, T2 for
T.ACT, T.RET, where T.ACT<-T1 and T1 is most recently used
2) In case primary path T.PRI not in {T1, T2} but ACTIVE, set
T.ACT<-T.PRI and T.RET<-T1
3) If only T1 is ACTIVE from the set, set T.ACT<-T1 and T.RET<-T1
4) If none is ACTIVE, set T.ACT<-best(T.PRI, T.RET, T3) where
T3 is the most recently used (if avail) in PF, set T.RET<-T.PRI
Prior to above commits, 4) was simply a camp on T.ACT<-T.PRI and
T.RET<-T.PRI, ignoring possible paths in PF. Camping on T.PRI is
still slightly suboptimal as it can lead to the following scenario:
Setup:
<A> <B>
T1: p1p1 (10.0.10.10) <==> .'`) <==> p1p1 (10.0.10.12) <= T.PRI
T2: p1p2 (10.0.10.20) <==> (_ . ) <==> p1p2 (10.0.10.22)
net.sctp.rto_min = 1000
net.sctp.path_max_retrans = 2
net.sctp.pf_retrans = 0
net.sctp.hb_interval = 1000
T.PRI is permanently down, T2 is put briefly into PF state (e.g. due to
link flapping). Here, the first time transmission is sent over PF path
T2 as it's the only non-INACTIVE path, but the retransmitted data-chunks
are sent over the INACTIVE path T1 (T.PRI), which is not good.
After the patch, it's choosing better transports in both cases by
modifying step 4):
4) If none is ACTIVE, set T.ACT_new<-best(T.ACT_old, T3) where T3 is
the most recently used (if avail) in PF, set T.RET<-T.ACT_new
This will still select a best possible path in PF if available (which
can also include T.PRI/T.RET), and set both T.ACT/T.RET to it.
In case sctp_assoc_control_transport() *just* put T.ACT_old into INACTIVE
as it transitioned from ACTIVE->PF->INACTIVE and stays in INACTIVE just
for a very short while before going back ACTIVE, it will guarantee that
this path will be reselected for T.ACT/T.RET since T3 (PF) is not
available.
Previously, this was not possible, as we would only select between T.PRI
and T.RET, and a possible T3 would be NULL due to the fact that we have
just transitioned T3 in sctp_assoc_control_transport() from PF->INACTIVE
and would select a suboptimal path when T.PRI/T.RET have worse properties.
In the case that T.ACT_old permanently went to INACTIVE during this
transition and there's no PF path available, plus T.PRI and T.RET are
INACTIVE as well, we would now camp on T.ACT_old, but if everything is
being INACTIVE there's really not much we can do except hoping for a
successful HB to bring one of the transports back up again and, thus
cause a new selection through sctp_assoc_control_transport().
Now both tests work fine:
Case 1:
1. T1 S(ACTIVE) T.ACT
T2 S(ACTIVE) T.RET
2. T1 S(ACTIVE) T.ACT, T.RET
T2 S(PF)
3. T1 S(ACTIVE) T.ACT, T.RET
T2 S(INACTIVE)
5. T1 S(PF) T.ACT, T.RET
T2 S(INACTIVE)
[ 5.1 T1 S(INACTIVE) T.ACT, T.RET
T2 S(INACTIVE) ]
6. T1 S(ACTIVE) T.ACT, T.RET
T2 S(INACTIVE)
7. T1 S(ACTIVE) T.ACT
T2 S(ACTIVE) T.RET
Case 2:
1. T1 S(ACTIVE) T.ACT
T2 S(ACTIVE) T.RET
2. T1 S(PF)
T2 S(ACTIVE) T.ACT, T.RET
3. T1 S(INACTIVE)
T2 S(ACTIVE) T.ACT, T.RET
5. T1 S(INACTIVE)
T2 S(PF) T.ACT, T.RET
[ 5.1 T1 S(INACTIVE)
T2 S(INACTIVE) T.ACT, T.RET ]
6. T1 S(INACTIVE)
T2 S(ACTIVE) T.ACT, T.RET
7. T1 S(ACTIVE) T.ACT
T2 S(ACTIVE) T.RET
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Acked-by: Neil Horman <nhorman@tuxdriver.com>
Acked-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-08-22 15:03:30 +04:00
trans_pri = sctp_trans_elect_best ( asoc - > peer . active_path , trans_pf ) ;
trans_sec = trans_pri ;
2014-06-11 20:19:29 +04:00
}
/* 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 23:51:06 +04:00
struct sctp_transport *
sctp_assoc_choose_alter_transport ( struct sctp_association * asoc ,
struct sctp_transport * last_sent_to )
2005-06-21 00:14:57 +04:00
{
2009-05-12 17:52:51 +04: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-21 00:14:57 +04: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 23:51:06 +04:00
if ( last_sent_to = = NULL ) {
2005-04-17 02:20:36 +04: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 23:51:06 +04:00
} else {
2009-05-12 17:52:51 +04:00
if ( last_sent_to = = asoc - > peer . retran_path )
2005-04-17 02:20:36 +04: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 23:51:06 +04:00
2005-04-17 02:20:36 +04:00
return asoc - > peer . retran_path ;
}
}
2018-04-26 22:58:55 +03:00
void sctp_assoc_update_frag_point ( struct sctp_association * asoc )
{
int frag = sctp_mtu_payload ( sctp_sk ( asoc - > base . sk ) , asoc - > pathmtu ,
sctp_datachk_len ( & asoc - > stream ) ) ;
if ( asoc - > user_frag )
frag = min_t ( int , frag , asoc - > user_frag ) ;
frag = min_t ( int , frag , SCTP_MAX_CHUNK_LEN -
sctp_datachk_len ( & asoc - > stream ) ) ;
asoc - > frag_point = SCTP_TRUNC4 ( frag ) ;
}
2018-04-26 22:58:53 +03:00
void sctp_assoc_set_pmtu ( struct sctp_association * asoc , __u32 pmtu )
{
2018-04-26 22:58:55 +03:00
if ( asoc - > pathmtu ! = pmtu ) {
2018-04-26 22:58:53 +03:00
asoc - > pathmtu = pmtu ;
2018-04-26 22:58:55 +03:00
sctp_assoc_update_frag_point ( asoc ) ;
}
2018-04-26 22:58:53 +03:00
pr_debug ( " %s: asoc:%p, pmtu:%d, frag_point:%d \n " , __func__ , asoc ,
asoc - > pathmtu , asoc - > frag_point ) ;
}
2005-04-17 02:20:36 +04:00
/* 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 .
*/
2017-04-04 08:39:55 +03:00
void sctp_assoc_sync_pmtu ( struct sctp_association * asoc )
2005-04-17 02:20:36 +04:00
{
struct sctp_transport * t ;
__u32 pmtu = 0 ;
if ( ! asoc )
return ;
/* Get the lowest pmtu of all the transports. */
2018-04-26 22:58:57 +03:00
list_for_each_entry ( t , & asoc - > peer . transport_addr_list , transports ) {
2007-06-07 22:21:05 +04:00
if ( t - > pmtu_pending & & t - > dst ) {
2018-10-15 14:58:29 +03:00
sctp_transport_update_pmtu ( t ,
atomic_read ( & t - > mtu_info ) ) ;
2007-06-07 22:21:05 +04:00
t - > pmtu_pending = 0 ;
}
2005-12-22 22:36:46 +03:00
if ( ! pmtu | | ( t - > pathmtu < pmtu ) )
pmtu = t - > pathmtu ;
2005-04-17 02:20:36 +04:00
}
2018-04-26 22:58:53 +03:00
sctp_assoc_set_pmtu ( asoc , pmtu ) ;
2005-04-17 02:20:36 +04:00
}
/* Should we send a SACK to update our peer? */
2013-12-06 05:36:29 +04:00
static inline bool sctp_peer_needs_update ( struct sctp_association * asoc )
2005-04-17 02:20:36 +04:00
{
2019-12-09 08:45:18 +03:00
struct net * net = asoc - > base . net ;
2005-04-17 02:20:36 +04: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 23:53:57 +03:00
( ( asoc - > rwnd - asoc - > a_rwnd ) > = max_t ( __u32 ,
2012-08-07 11:29:57 +04:00
( asoc - > base . sk - > sk_rcvbuf > > net - > sctp . rwnd_upd_shift ) ,
2009-11-23 23:53:57 +03:00
asoc - > pathmtu ) ) )
2013-12-06 05:36:29 +04:00
return true ;
2005-04-17 02:20:36 +04:00
break ;
default :
break ;
}
2013-12-06 05:36:29 +04:00
return false ;
2005-04-17 02:20:36 +04: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 23:45:17 +04: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-17 02:20:36 +04: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 23:45:17 +04: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-17 02:20:36 +04: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 23:45:17 +04: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 .
*/
sctp: fix recovering from 0 win with small data chunks
Currently if SCTP closes the receive window with window pressure, mostly
caused by excessive skb overhead on payload/overheads ratio, SCTP will
close the window abruptly while saving the delta on rwnd_press. It will
start recovering rwnd as the chunks are consumed by the application and
the rwnd_press will be only recovered after rwnd reach the same value as
of rwnd_press, mostly to prevent silly window syndrome.
Thing is, this is very inefficient with small data chunks, as with those
it will never reach back that value, and thus it will never recover from
such pressure. This means that we will not issue window updates when
recovering from 0 window and will rely on a sender retransmit to notice
it.
The fix here is to remove such threshold, as no value is good enough: it
depends on the (avg) chunk sizes being used.
Test with netperf -t SCTP_STREAM -- -m 1, and trigger 0 window by
sending SIGSTOP to netserver, sleep 1.2, and SIGCONT.
Rate limited to 845kbps, for visibility. Capture done at netserver side.
Previously:
01.500751 IP B.48277 > A.36925: sctp (1) [SACK] [cum ack 632372996] [a_rwnd 99153] [
01.500752 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632372997] [SID: 0] [SS
01.517471 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632373010] [SID: 0] [SS
01.517483 IP B.48277 > A.36925: sctp (1) [SACK] [cum ack 632373009] [a_rwnd 0] [#gap
01.517485 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632373083] [SID: 0] [SS
01.517488 IP B.48277 > A.36925: sctp (1) [SACK] [cum ack 632373009] [a_rwnd 0] [#gap
01.534168 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632373096] [SID: 0] [SS
01.534180 IP B.48277 > A.36925: sctp (1) [SACK] [cum ack 632373009] [a_rwnd 0] [#gap
01.534181 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632373169] [SID: 0] [SS
01.534185 IP B.48277 > A.36925: sctp (1) [SACK] [cum ack 632373009] [a_rwnd 0] [#gap
02.525978 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632373010] [SID: 0] [SS
02.526021 IP B.48277 > A.36925: sctp (1) [SACK] [cum ack 632373009] [a_rwnd 0] [#gap
(window update missed)
04.573807 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632373010] [SID: 0] [SS
04.779370 IP B.48277 > A.36925: sctp (1) [SACK] [cum ack 632373082] [a_rwnd 859] [#g
04.789162 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632373083] [SID: 0] [SS
04.789323 IP A.36925 > B.48277: sctp (1) [DATA] (B)(E) [TSN: 632373156] [SID: 0] [SS
04.789372 IP B.48277 > A.36925: sctp (1) [SACK] [cum ack 632373228] [a_rwnd 786] [#g
After:
02.568957 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098728] [a_rwnd 99153]
02.568961 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098729] [SID: 0] [S
02.585631 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098742] [SID: 0] [S
02.585666 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 0] [#ga
02.585671 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098815] [SID: 0] [S
02.585683 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 0] [#ga
02.602330 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098828] [SID: 0] [S
02.602359 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 0] [#ga
02.602363 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098901] [SID: 0] [S
02.602372 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 0] [#ga
03.600788 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098742] [SID: 0] [S
03.600830 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 0] [#ga
03.619455 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 13508]
03.619479 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 27017]
03.619497 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 40526]
03.619516 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 54035]
03.619533 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 67544]
03.619552 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 81053]
03.619570 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098741] [a_rwnd 94562]
(following data transmission triggered by window updates above)
03.633504 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098742] [SID: 0] [S
03.836445 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098814] [a_rwnd 100000]
03.843125 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098815] [SID: 0] [S
03.843285 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098888] [SID: 0] [S
03.843345 IP B.50536 > A.55173: sctp (1) [SACK] [cum ack 2490098960] [a_rwnd 99894]
03.856546 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490098961] [SID: 0] [S
03.866450 IP A.55173 > B.50536: sctp (1) [DATA] (B)(E) [TSN: 2490099011] [SID: 0] [S
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-23 19:29:37 +03:00
if ( asoc - > rwnd_press ) {
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 23:45:17 +04:00
int change = min ( asoc - > pathmtu , asoc - > rwnd_press ) ;
asoc - > rwnd + = change ;
asoc - > rwnd_press - = change ;
}
2009-09-05 02:20:59 +04: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 23:45:17 +04: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-17 02:20:36 +04: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 23:45:17 +04:00
if ( sctp_peer_needs_update ( asoc ) ) {
2005-04-17 02:20:36 +04: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 21:49:40 +04: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-17 02:20:36 +04:00
sack = sctp_make_sack ( asoc ) ;
if ( ! sack )
return ;
asoc - > peer . sack_needed = 0 ;
2016-03-11 00:33:07 +03:00
sctp_outq_tail ( & asoc - > outqueue , sack , GFP_ATOMIC ) ;
2005-04-17 02:20:36 +04:00
/* Stop the SACK timer. */
timer = & asoc - > timers [ SCTP_EVENT_TIMEOUT_SACK ] ;
2013-02-04 00:32:57 +04:00
if ( del_timer ( timer ) )
2005-04-17 02:20:36 +04: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 23:45:17 +04: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
2020-08-23 02:15:55 +03:00
* potential pressure overflow so that the window can be restored
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 23:45:17 +04:00
* 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 {
sctp: do not loose window information if in rwnd_over
It's possible that we receive a packet that is larger than current
window. If it's the first packet in this way, it will cause it to
increase rwnd_over. Then, if we receive another data chunk (specially as
SCTP allows you to have one data chunk in flight even during 0 window),
rwnd_over will be overwritten instead of added to.
In the long run, this could cause the window to grow bigger than its
initial size, as rwnd_over would be charged only for the last received
data chunk while the code will try open the window for all packets that
were received and had its value in rwnd_over overwritten. This, then,
can lead to the worsening of payload/buffer ratio and cause rwnd_press
to kick in more often.
The fix is to sum it too, same as is done for rwnd_press, so that if we
receive 3 chunks after closing the window, we still have to release that
same amount before re-opening it.
Log snippet from sctp_test exhibiting the issue:
[ 146.209232] sctp: sctp_assoc_rwnd_decrease: asoc:ffff88013928e000
rwnd decreased by 1 to (0, 1, 114221)
[ 146.209232] sctp: sctp_assoc_rwnd_decrease:
association:ffff88013928e000 has asoc->rwnd:0, asoc->rwnd_over:1!
[ 146.209232] sctp: sctp_assoc_rwnd_decrease: asoc:ffff88013928e000
rwnd decreased by 1 to (0, 1, 114221)
[ 146.209232] sctp: sctp_assoc_rwnd_decrease:
association:ffff88013928e000 has asoc->rwnd:0, asoc->rwnd_over:1!
[ 146.209232] sctp: sctp_assoc_rwnd_decrease: asoc:ffff88013928e000
rwnd decreased by 1 to (0, 1, 114221)
[ 146.209232] sctp: sctp_assoc_rwnd_decrease:
association:ffff88013928e000 has asoc->rwnd:0, asoc->rwnd_over:1!
[ 146.209232] sctp: sctp_assoc_rwnd_decrease: asoc:ffff88013928e000
rwnd decreased by 1 to (0, 1, 114221)
Signed-off-by: Marcelo Ricardo Leitner <marcelo.leitner@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2016-12-23 19:29:02 +03:00
asoc - > rwnd_over + = len - asoc - > rwnd ;
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 23:45:17 +04:00
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-17 02:20:36 +04:00
/* Build the bind address list for the association based on info from the
* local endpoint and the remote peer .
*/
2005-07-12 07:57:47 +04:00
int sctp_assoc_set_bind_addr_from_ep ( struct sctp_association * asoc ,
2017-08-05 14:59:54 +03:00
enum sctp_scope scope , gfp_t gfp )
2005-04-17 02:20:36 +04:00
{
2020-06-24 23:34:18 +03:00
struct sock * sk = asoc - > base . sk ;
2005-04-17 02:20:36 +04:00
int flags ;
/* Use scoping rules to determine the subset of addresses from
* the endpoint .
*/
2020-06-24 23:34:18 +03:00
flags = ( PF_INET6 = = sk - > sk_family ) ? SCTP_ADDR6_ALLOWED : 0 ;
if ( ! inet_v6_ipv6only ( sk ) )
flags | = SCTP_ADDR4_ALLOWED ;
2005-04-17 02:20:36 +04:00
if ( asoc - > peer . ipv4_address )
flags | = SCTP_ADDR4_PEERSUPP ;
if ( asoc - > peer . ipv6_address )
flags | = SCTP_ADDR6_PEERSUPP ;
2019-12-09 08:45:18 +03:00
return sctp_bind_addr_copy ( asoc - > base . net ,
2012-08-06 12:42:04 +04:00
& asoc - > base . bind_addr ,
2005-04-17 02:20:36 +04: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 07:57:47 +04:00
struct sctp_cookie * cookie ,
2005-10-07 10:46:04 +04:00
gfp_t gfp )
2005-04-17 02:20:36 +04:00
{
2023-04-19 18:16:31 +03:00
struct sctp_init_chunk * peer_init = ( struct sctp_init_chunk * ) ( cookie + 1 ) ;
int var_size2 = ntohs ( peer_init - > chunk_hdr . length ) ;
2005-04-17 02:20:36 +04:00
int var_size3 = cookie - > raw_addr_list_len ;
2023-04-19 18:16:31 +03:00
__u8 * raw = ( __u8 * ) peer_init + var_size2 ;
2005-04-17 02:20:36 +04:00
return sctp_raw_to_bind_addrs ( & asoc - > base . bind_addr , raw , var_size3 ,
asoc - > ep - > base . bind_addr . port , gfp ) ;
}
2007-02-09 17:25:18 +03:00
/* Lookup laddr in the bind address list of an association. */
int sctp_assoc_lookup_laddr ( struct sctp_association * asoc ,
2005-04-17 02:20:36 +04:00
const union sctp_addr * laddr )
{
2007-09-17 03:03:28 +04:00
int found = 0 ;
2005-04-17 02:20:36 +04:00
if ( ( asoc - > base . bind_addr . port = = ntohs ( laddr - > v4 . sin_port ) ) & &
sctp_bind_addr_match ( & asoc - > base . bind_addr , laddr ,
2007-09-17 03:03:28 +04:00
sctp_sk ( asoc - > base . sk ) ) )
2005-04-17 02:20:36 +04:00
found = 1 ;
return found ;
}
2007-05-05 00:55:27 +04:00
/* Set an association id for a given association */
int sctp_assoc_set_id ( struct sctp_association * asoc , gfp_t gfp )
{
2015-11-07 03:28:21 +03:00
bool preload = gfpflags_allow_blocking ( gfp ) ;
2013-02-28 05:05:00 +04:00
int ret ;
2009-06-01 20:41:15 +04:00
/* If the id is already assigned, keep it. */
if ( asoc - > assoc_id )
2013-02-28 05:05:00 +04:00
return 0 ;
2007-05-05 00:55:27 +04:00
2013-02-28 05:05:00 +04:00
if ( preload )
idr_preload ( gfp ) ;
2007-05-05 00:55:27 +04:00
spin_lock_bh ( & sctp_assocs_id_lock ) ;
2019-01-28 10:08:23 +03:00
/* 0, 1, 2 are used as SCTP_FUTURE_ASSOC, SCTP_CURRENT_ASSOC and
* SCTP_ALL_ASSOC , so an available id must be > SCTP_ALL_ASSOC .
*/
ret = idr_alloc_cyclic ( & sctp_assocs_id , asoc , SCTP_ALL_ASSOC + 1 , 0 ,
GFP_NOWAIT ) ;
2007-05-05 00:55:27 +04:00
spin_unlock_bh ( & sctp_assocs_id_lock ) ;
2013-02-28 05:05:00 +04:00
if ( preload )
idr_preload_end ( ) ;
if ( ret < 0 )
return ret ;
2007-05-05 00:55:27 +04:00
2013-02-28 05:05:00 +04:00
asoc - > assoc_id = ( sctp_assoc_t ) ret ;
return 0 ;
2007-05-05 00:55:27 +04:00
}
2007-12-21 01:11:47 +03:00
2011-05-25 01:48:02 +04: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-21 01:11:47 +03: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 05:57:33 +04:00
/* We can remove all the entries from the queue up to
2007-12-21 01:11:47 +03: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 17:35:04 +03:00
struct sctp_chunk * ack ;
2007-12-21 01:11:47 +03: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 ) {
net: sctp: fix panic on duplicate ASCONF chunks
When receiving a e.g. semi-good formed connection scan in the
form of ...
-------------- INIT[ASCONF; ASCONF_ACK] ------------->
<----------- INIT-ACK[ASCONF; ASCONF_ACK] ------------
-------------------- COOKIE-ECHO -------------------->
<-------------------- COOKIE-ACK ---------------------
---------------- ASCONF_a; ASCONF_b ----------------->
... where ASCONF_a equals ASCONF_b chunk (at least both serials
need to be equal), we panic an SCTP server!
The problem is that good-formed ASCONF chunks that we reply with
ASCONF_ACK chunks are cached per serial. Thus, when we receive a
same ASCONF chunk twice (e.g. through a lost ASCONF_ACK), we do
not need to process them again on the server side (that was the
idea, also proposed in the RFC). Instead, we know it was cached
and we just resend the cached chunk instead. So far, so good.
Where things get nasty is in SCTP's side effect interpreter, that
is, sctp_cmd_interpreter():
While incoming ASCONF_a (chunk = event_arg) is being marked
!end_of_packet and !singleton, and we have an association context,
we do not flush the outqueue the first time after processing the
ASCONF_ACK singleton chunk via SCTP_CMD_REPLY. Instead, we keep it
queued up, although we set local_cork to 1. Commit 2e3216cd54b1
changed the precedence, so that as long as we get bundled, incoming
chunks we try possible bundling on outgoing queue as well. Before
this commit, we would just flush the output queue.
Now, while ASCONF_a's ASCONF_ACK sits in the corked outq, we
continue to process the same ASCONF_b chunk from the packet. As
we have cached the previous ASCONF_ACK, we find it, grab it and
do another SCTP_CMD_REPLY command on it. So, effectively, we rip
the chunk->list pointers and requeue the same ASCONF_ACK chunk
another time. Since we process ASCONF_b, it's correctly marked
with end_of_packet and we enforce an uncork, and thus flush, thus
crashing the kernel.
Fix it by testing if the ASCONF_ACK is currently pending and if
that is the case, do not requeue it. When flushing the output
queue we may relink the chunk for preparing an outgoing packet,
but eventually unlink it when it's copied into the skb right
before transmission.
Joint work with Vlad Yasevich.
Fixes: 2e3216cd54b1 ("sctp: Follow security requirement of responding with 1 packet")
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Signed-off-by: Vlad Yasevich <vyasevich@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
2014-10-10 00:55:32 +04:00
if ( sctp_chunk_pending ( ack ) )
continue ;
2007-12-21 01:11:47 +03:00
if ( ack - > subh . addip_hdr - > serial = = serial ) {
sctp_chunk_hold ( ack ) ;
2008-02-05 17:35:04 +03:00
return ack ;
2007-12-21 01:11:47 +03:00
}
}
2008-02-05 17:35:04 +03:00
return NULL ;
2007-12-21 01:11:47 +03:00
}
2011-05-30 03:23:36 +04: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 ) ;
}