<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/net/sctp/sm_sideeffect.c, branch linux-3.8.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.8.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-3.8.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2012-12-03T18:32:15Z</updated>
<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>
<entry>
<title>sctp: be more restrictive in transport selection on bundled sacks</title>
<updated>2012-07-01T05:44:35Z</updated>
<author>
<name>Neil Horman</name>
</author>
<published>2012-06-30T03:04:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4244854d22bf8f782698c5224b9191c8d2d42610'/>
<id>urn:sha1:4244854d22bf8f782698c5224b9191c8d2d42610</id>
<content type='text'>
It was noticed recently that when we send data on a transport, its possible that
we might bundle a sack that arrived on a different transport.  While this isn't
a major problem, it does go against the SHOULD requirement in section 6.4 of RFC
2960:

 An endpoint SHOULD transmit reply chunks (e.g., SACK, HEARTBEAT ACK,
   etc.) to the same destination transport address from which it
   received the DATA or control chunk to which it is replying.  This
   rule should also be followed if the endpoint is bundling DATA chunks
   together with the reply chunk.

This patch seeks to correct that.  It restricts the bundling of sack operations
to only those transports which have moved the ctsn of the association forward
since the last sack.  By doing this we guarantee that we only bundle outbound
saks on a transport that has received a chunk since the last sack.  This brings
us into stricter compliance with the RFC.

Vlad had initially suggested that we strictly allow only sack bundling on the
transport that last moved the ctsn forward.  While this makes sense, I was
concerned that doing so prevented us from bundling in the case where we had
received chunks that moved the ctsn on multiple transports.  In those cases, the
RFC allows us to select any of the transports having received chunks to bundle
the sack on.  so I've modified the approach to allow for that, by adding a state
variable to each transport that tracks weather it has moved the ctsn since the
last sack.  This I think keeps our behavior (and performance), close enough to
our current profile that I think we can do this without a sysctl knob to
enable/disable it.

Signed-off-by: Neil Horman &lt;nhorman@tuxdriver.com&gt;
CC: Vlad Yaseivch &lt;vyasevich@gmail.com&gt;
CC: David S. Miller &lt;davem@davemloft.net&gt;
CC: linux-sctp@vger.kernel.org
Reported-by: Michele Baldessari &lt;michele@redhat.com&gt;
Reported-by: sorin serban &lt;sserban@redhat.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>net: Convert net_ratelimit uses to net_&lt;level&gt;_ratelimited</title>
<updated>2012-05-15T17:45:03Z</updated>
<author>
<name>Joe Perches</name>
</author>
<published>2012-05-13T21:56:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=e87cc4728f0e2fb663e592a1141742b1d6c63256'/>
<id>urn:sha1:e87cc4728f0e2fb663e592a1141742b1d6c63256</id>
<content type='text'>
Standardize the net core ratelimited logging functions.

Coalesce formats, align arguments.
Change a printk then vprintk sequence to use printf extension %pV.

Signed-off-by: Joe Perches &lt;joe@perches.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
