<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/sctp/sm_sideeffect.c, branch linux-3.10.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.10.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.10.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2016-08-27T09:40:33Z</updated>
<entry>
<title>sctp: Prevent soft lockup when sctp_accept() is called during a timeout event</title>
<updated>2016-08-27T09:40:33Z</updated>
<author>
<name>Karl Heiss</name>
</author>
<published>2015-09-24T16:15:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1cf7c76efb3c0f5439d2c9461502f33817469371'/>
<id>urn:sha1:1cf7c76efb3c0f5439d2c9461502f33817469371</id>
<content type='text'>
commit 635682a14427d241bab7bbdeebb48a7d7b91638e upstream.

A case can occur when sctp_accept() is called by the user during
a heartbeat timeout event after the 4-way handshake.  Since
sctp_assoc_migrate() changes both assoc-&gt;base.sk and assoc-&gt;ep, the
bh_sock_lock in sctp_generate_heartbeat_event() will be taken with
the listening socket but released with the new association socket.
The result is a deadlock on any future attempts to take the listening
socket lock.

Note that this race can occur with other SCTP timeouts that take
the bh_lock_sock() in the event sctp_accept() is called.

 BUG: soft lockup - CPU#9 stuck for 67s! [swapper:0]
 ...
 RIP: 0010:[&lt;ffffffff8152d48e&gt;]  [&lt;ffffffff8152d48e&gt;] _spin_lock+0x1e/0x30
 RSP: 0018:ffff880028323b20  EFLAGS: 00000206
 RAX: 0000000000000002 RBX: ffff880028323b20 RCX: 0000000000000000
 RDX: 0000000000000000 RSI: ffff880028323be0 RDI: ffff8804632c4b48
 RBP: ffffffff8100bb93 R08: 0000000000000000 R09: 0000000000000000
 R10: ffff880610662280 R11: 0000000000000100 R12: ffff880028323aa0
 R13: ffff8804383c3880 R14: ffff880028323a90 R15: ffffffff81534225
 FS:  0000000000000000(0000) GS:ffff880028320000(0000) knlGS:0000000000000000
 CS:  0010 DS: 0018 ES: 0018 CR0: 000000008005003b
 CR2: 00000000006df528 CR3: 0000000001a85000 CR4: 00000000000006e0
 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
 Process swapper (pid: 0, threadinfo ffff880616b70000, task ffff880616b6cab0)
 Stack:
 ffff880028323c40 ffffffffa01c2582 ffff880614cfb020 0000000000000000
 &lt;d&gt; 0100000000000000 00000014383a6c44 ffff8804383c3880 ffff880614e93c00
 &lt;d&gt; ffff880614e93c00 0000000000000000 ffff8804632c4b00 ffff8804383c38b8
 Call Trace:
 &lt;IRQ&gt;
 [&lt;ffffffffa01c2582&gt;] ? sctp_rcv+0x492/0xa10 [sctp]
 [&lt;ffffffff8148c559&gt;] ? nf_iterate+0x69/0xb0
 [&lt;ffffffff814974a0&gt;] ? ip_local_deliver_finish+0x0/0x2d0
 [&lt;ffffffff8148c716&gt;] ? nf_hook_slow+0x76/0x120
 [&lt;ffffffff814974a0&gt;] ? ip_local_deliver_finish+0x0/0x2d0
 [&lt;ffffffff8149757d&gt;] ? ip_local_deliver_finish+0xdd/0x2d0
 [&lt;ffffffff81497808&gt;] ? ip_local_deliver+0x98/0xa0
 [&lt;ffffffff81496ccd&gt;] ? ip_rcv_finish+0x12d/0x440
 [&lt;ffffffff81497255&gt;] ? ip_rcv+0x275/0x350
 [&lt;ffffffff8145cfeb&gt;] ? __netif_receive_skb+0x4ab/0x750
 ...

With lockdep debugging:

 =====================================
 [ BUG: bad unlock balance detected! ]
 -------------------------------------
 CslRx/12087 is trying to release lock (slock-AF_INET) at:
 [&lt;ffffffffa01bcae0&gt;] sctp_generate_timeout_event+0x40/0xe0 [sctp]
 but there are no more locks to release!

 other info that might help us debug this:
 2 locks held by CslRx/12087:
 #0:  (&amp;asoc-&gt;timers[i]){+.-...}, at: [&lt;ffffffff8108ce1f&gt;] run_timer_softirq+0x16f/0x3e0
 #1:  (slock-AF_INET){+.-...}, at: [&lt;ffffffffa01bcac3&gt;] sctp_generate_timeout_event+0x23/0xe0 [sctp]

Ensure the socket taken is also the same one that is released by
saving a copy of the socket before entering the timeout event
critical section.

Signed-off-by: Karl Heiss &lt;kheiss@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
[wt: adjusted, 3.10 uses sctp_bh_unlock_sock() instead of bh_lock_sock()]

Signed-off-by: Willy Tarreau &lt;w@1wt.eu&gt;
</content>
</entry>
<entry>
<title>net: remove redundant check for timer pending state before del_timer</title>
<updated>2013-02-04T18:26:49Z</updated>
<author>
<name>Ying Xue</name>
</author>
<published>2013-02-03T20:32:57Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=25cc4ae913a46bcc11b03c37bec59568f2122a36'/>
<id>urn:sha1:25cc4ae913a46bcc11b03c37bec59568f2122a36</id>
<content type='text'>
As in del_timer() there has already placed a timer_pending() function
to check whether the timer to be deleted is pending or not, it's
unnecessary to check timer pending state again before del_timer() is
called.

Signed-off-by: Ying Xue &lt;ying.xue@windriver.com&gt;
Cc: Eric Dumazet &lt;edumazet@google.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Add support to per-association statistics via a new SCTP_GET_ASSOC_STATS call</title>
<updated>2012-12-03T18:32:15Z</updated>
<author>
<name>Michele Baldessari</name>
</author>
<published>2012-12-01T04:49:42Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=196d67593439b03088913227093e374235596e33'/>
<id>urn:sha1:196d67593439b03088913227093e374235596e33</id>
<content type='text'>
The current SCTP stack is lacking a mechanism to have per association
statistics. This is an implementation modeled after OpenSolaris'
SCTP_GET_ASSOC_STATS.

Userspace part will follow on lksctp if/when there is a general ACK on
this.
V4:
- Move ipackets++ before q-&gt;immediate.func() for consistency reasons
- Move sctp_max_rto() at the end of sctp_transport_update_rto() to avoid
  returning bogus RTO values
- return asoc-&gt;rto_min when max_obs_rto value has not changed

V3:
- Increase ictrlchunks in sctp_assoc_bh_rcv() as well
- Move ipackets++ to sctp_inq_push()
- return 0 when no rto updates took place since the last call

V2:
- Implement partial retrieval of stat struct to cope for future expansion
- Kill the rtxpackets counter as it cannot be precise anyway
- Rename outseqtsns to outofseqtsns to make it clearer that these are out
  of sequence unexpected TSNs
- Move asoc-&gt;ipackets++ under a lock to avoid potential miscounts
- Fold asoc-&gt;opackets++ into the already existing asoc check
- Kill unneeded (q-&gt;asoc) test when increasing rtxchunks
- Do not count octrlchunks if sending failed (SCTP_XMIT_OK != 0)
- Don't count SHUTDOWNs as SACKs
- Move SCTP_GET_ASSOC_STATS to the private space API
- Adjust the len check in sctp_getsockopt_assoc_stats() to allow for
  future struct growth
- Move association statistics in their own struct
- Update idupchunks when we send a SACK with dup TSNs
- return min_rto in max_rto when RTO has not changed. Also return the
  transport when max_rto last changed.

Signed-off: Michele Baldessari &lt;michele@acksyn.org&gt;
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;

Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: send abort chunk when max_retrans exceeded</title>
<updated>2012-11-20T20:50:37Z</updated>
<author>
<name>Neil Horman</name>
</author>
<published>2012-11-20T10:14:30Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=de4594a51c904ddcd6c3a6cdd100f7c1d94d3239'/>
<id>urn:sha1:de4594a51c904ddcd6c3a6cdd100f7c1d94d3239</id>
<content type='text'>
In the event that an association exceeds its max_retrans attempts, we should
send an ABORT chunk indicating that we are closing the assocation as a result.
Because of the nature of the error, its unlikely to be received, but its a nice
clean way to close the association if it does make it through, and it will give
anyone watching via tcpdump a clue as to what happened.

Change notes:
v2)
	* Removed erroneous changes from sctp_make_violation_parmlen

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: linux-sctp@vger.kernel.org
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Clean up type-punning in sctp_cmd_t union</title>
<updated>2012-11-03T18:54:55Z</updated>
<author>
<name>Neil Horman</name>
</author>
<published>2012-10-29T08:32:13Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=b26ddd813031666293c95e84c997eb8b1f97bd38'/>
<id>urn:sha1:b26ddd813031666293c95e84c997eb8b1f97bd38</id>
<content type='text'>
Lots of points in the sctp_cmd_interpreter function treat the sctp_cmd_t arg as
a void pointer, even though they are written as various other types.  Theres no
need for this as doing so just leads to possible type-punning issues that could
cause crashes, and if we remain type-consistent we can actually just remove the
void * member of the union entirely.

Change Notes:

v2)
	* Dropped chunk that modified SCTP_NULL to create a marker pattern
	 should anyone try to use a SCTP_NULL() assigned sctp_arg_t, Assigning
	 to .zero provides the same effect and should be faster, per Vlad Y.

v3)
	* Reverted part of V2, opting to use memset instead of .zero, so that
	 the entire union is initalized thus avoiding the i164 speculative load
	 problems previously encountered, per Dave M..  Also rewrote
	 SCTP_[NO]FORCE so as to use common infrastructure a little more

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com
CC: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: linux-sctp@vger.kernel.org
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: fix call to SCTP_CMD_PROCESS_SACK in sctp_cmd_interpreter()</title>
<updated>2012-10-16T18:41:46Z</updated>
<author>
<name>Zijie Pan</name>
</author>
<published>2012-10-15T03:56:39Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f6e80abeab928b7c47cc1fbf53df13b4398a2bec'/>
<id>urn:sha1:f6e80abeab928b7c47cc1fbf53df13b4398a2bec</id>
<content type='text'>
Bug introduced by commit edfee0339e681a784ebacec7e8c2dc97dc6d2839
(sctp: check src addr when processing SACK to update transport state)

Signed-off-by: Zijie Pan &lt;zijie.pan@6wind.com&gt;
Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: check src addr when processing SACK to update transport state</title>
<updated>2012-10-04T19:53:48Z</updated>
<author>
<name>Nicolas Dichtel</name>
</author>
<published>2012-10-03T05:43:22Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=edfee0339e681a784ebacec7e8c2dc97dc6d2839'/>
<id>urn:sha1:edfee0339e681a784ebacec7e8c2dc97dc6d2839</id>
<content type='text'>
Suppose we have an SCTP connection with two paths. After connection is
established, path1 is not available, thus this path is marked as inactive. Then
traffic goes through path2, but for some reasons packets are delayed (after
rto.max). Because packets are delayed, the retransmit mechanism will switch
again to path1. At this time, we receive a delayed SACK from path2. When we
update the state of the path in sctp_check_transmitted(), we do not take into
account the source address of the SACK, hence we update the wrong path.

Signed-off-by: Nicolas Dichtel &lt;nicolas.dichtel@6wind.com&gt;
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Push struct net down into all of the state machine functions</title>
<updated>2012-08-15T06:30:37Z</updated>
<author>
<name>Eric W. Biederman</name>
</author>
<published>2012-08-07T07:28:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=24cb81a6a91288fcba19548944729ea906eb5e2a'/>
<id>urn:sha1:24cb81a6a91288fcba19548944729ea906eb5e2a</id>
<content type='text'>
There are a handle of state machine functions primarily those dealing
with processing INIT packets where there is neither a valid endpoint nor
a valid assoication from which to derive a struct net.  Therefore add
struct net * to the parameter list of sctp_state_fn_t and update all of
the state machine functions.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Push struct net down to sctp_chunk_event_lookup</title>
<updated>2012-08-15T06:30:37Z</updated>
<author>
<name>Eric W. Biederman</name>
</author>
<published>2012-08-07T07:25:24Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=55e26eb95a5345a5796babac98de6d6c42771df1'/>
<id>urn:sha1:55e26eb95a5345a5796babac98de6d6c42771df1</id>
<content type='text'>
This trickles up through sctp_sm_lookup_event up to sctp_do_sm
and up further into sctp_primitiv_NAME before the code reaches
places where struct net can be reliably found.

Signed-off-by: "Eric W. Biederman" &lt;ebiederm@xmission.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Implement quick failover draft from tsvwg</title>
<updated>2012-07-22T19:13:46Z</updated>
<author>
<name>Neil Horman</name>
</author>
<published>2012-07-21T07:56:07Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=5aa93bcf66f4af094d6f11096e81d5501a0b4ba5'/>
<id>urn:sha1:5aa93bcf66f4af094d6f11096e81d5501a0b4ba5</id>
<content type='text'>
I've seen several attempts recently made to do quick failover of sctp transports
by reducing various retransmit timers and counters.  While its possible to
implement a faster failover on multihomed sctp associations, its not
particularly robust, in that it can lead to unneeded retransmits, as well as
false connection failures due to intermittent latency on a network.

Instead, lets implement the new ietf quick failover draft found here:
http://tools.ietf.org/html/draft-nishida-tsvwg-sctp-failover-05

This will let the sctp stack identify transports that have had a small number of
errors, and avoid using them quickly until their reliability can be
re-established.  I've tested this out on two virt guests connected via multiple
isolated virt networks and believe its in compliance with the above draft and
works well.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
CC: Sridhar Samudrala &lt;sri@us.ibm.com&gt;
CC: "David S. Miller" &lt;davem@davemloft.net&gt;
CC: linux-sctp@vger.kernel.org
CC: joe@perches.com
Acked-by: Vlad Yasevich &lt;vyasevich@gmail.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
