<feed xmlns='http://www.w3.org/2005/Atom'>
<title>linux/include/net/sctp/command.h, branch v3.0.62</title>
<subtitle>Linux kernel source tree</subtitle>
<id>https://git.amat.us/linux/atom/include/net/sctp/command.h?h=v3.0.62</id>
<link rel='self' href='https://git.amat.us/linux/atom/include/net/sctp/command.h?h=v3.0.62'/>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/'/>
<updated>2011-07-07T21:08:44Z</updated>
<entry>
<title>sctp: Enforce retransmission limit during shutdown</title>
<updated>2011-07-07T21:08:44Z</updated>
<author>
<name>Thomas Graf</name>
<email>tgraf@infradead.org</email>
</author>
<published>2011-07-07T00:28:35Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f8d9605243280f1870dd2c6c37a735b925c15f3c'/>
<id>urn:sha1:f8d9605243280f1870dd2c6c37a735b925c15f3c</id>
<content type='text'>
When initiating a graceful shutdown while having data chunks
on the retransmission queue with a peer which is in zero
window mode the shutdown is never completed because the
retransmission error count is reset periodically by the
following two rules:

 - Do not timeout association while doing zero window probe.
 - Reset overall error count when a heartbeat request has
   been acknowledged.

The graceful shutdown will wait for all outstanding TSN to
be acknowledged before sending the SHUTDOWN request. This
never happens due to the peer's zero window not acknowledging
the continuously retransmitted data chunks. Although the
error counter is incremented for each failed retransmission,
the receiving of the SACK announcing the zero window clears
the error count again immediately. Also heartbeat requests
continue to be sent periodically. The peer acknowledges these
requests causing the error counter to be reset as well.

This patch changes behaviour to only reset the overall error
counter for the above rules while not in shutdown. After
reaching the maximum number of retransmission attempts, the
T5 shutdown guard timer is scheduled to give the receiver
some additional time to recover. The timer is stopped as soon
as the receiver acknowledges any data.

The issue can be easily reproduced by establishing a sctp
association over the loopback device, constantly queueing
data at the sender while not reading any at the receiver.
Wait for the window to reach zero, then initiate a shutdown
by killing both processes simultaneously. The association
will never be freed and the chunks on the retransmission
queue will be retransmitted indefinitely.

Signed-off-by: Thomas Graf &lt;tgraf@infradead.org&gt;
Acked-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: stop pending timers and purge queues when peer restart asoc</title>
<updated>2011-05-31T22:29:17Z</updated>
<author>
<name>Wei Yongjun</name>
<email>yjwei@cn.fujitsu.com</email>
</author>
<published>2011-05-29T23:23:36Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=a000c01e60e40e15304ffe48fff051d17a7bea91'/>
<id>urn:sha1:a000c01e60e40e15304ffe48fff051d17a7bea91</id>
<content type='text'>
If the peer restart the asoc, we should not only fail any unsent/unacked
data, but also stop the T3-rtx, SACK, T4-rto timers, and teardown ASCONF
queues.

Signed-off-by: Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: kill abandoned SCTP_CMD_TRANSMIT command</title>
<updated>2011-04-20T04:45:19Z</updated>
<author>
<name>Shan Wei</name>
<email>shanwei@cn.fujitsu.com</email>
</author>
<published>2011-04-18T19:12:40Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=66009927f1e7374afdc6f9fdd25c493ee4eadf7c'/>
<id>urn:sha1:66009927f1e7374afdc6f9fdd25c493ee4eadf7c</id>
<content type='text'>
Remove SCTP_CMD_TRANSMIT command as it never be used.

Signed-off-by: Shan Wei &lt;shanwei@cn.fujitsu.com&gt;
Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
Signed-off-by: Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: kill unused macros in head file</title>
<updated>2010-11-29T17:41:12Z</updated>
<author>
<name>Shan Wei</name>
<email>shanwei@cn.fujitsu.com</email>
</author>
<published>2010-11-29T00:14:58Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=49b4a6546fac02f58784f0744e0f99a6562ccc03'/>
<id>urn:sha1:49b4a6546fac02f58784f0744e0f99a6562ccc03</id>
<content type='text'>
1. SCTP_CMD_NUM_VERBS,SCTP_CMD_MAX
These two macros have never been used for several years since v2.6.12-rc2.

2.sctp_port_rover,sctp_port_alloc_lock
The commit 063930 abandoned global variables of port_rover and port_alloc_lock,
but still keep two macros to refer to them.
So, remove them now.

commit 06393009000779b00a558fd2f280882cc7dc2008
Author: Stephen Hemminger &lt;shemminger@linux-foundation.org&gt;
Date:   Wed Oct 10 17:30:18 2007 -0700

    [SCTP]: port randomization

Signed-off-by: Shan Wei &lt;shanwei@cn.fujitsu.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Fix oops when sending queued ASCONF chunks</title>
<updated>2010-04-28T19:16:34Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vladislav.yasevich@hp.com</email>
</author>
<published>2010-04-28T08:47:22Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=c0786693404cffd80ca3cb6e75ee7b35186b2825'/>
<id>urn:sha1:c0786693404cffd80ca3cb6e75ee7b35186b2825</id>
<content type='text'>
When we finish processing ASCONF_ACK chunk, we try to send
the next queued ASCONF.  This action runs the sctp state
machine recursively and it's not prepared to do so.

kernel BUG at kernel/timer.c:790!
invalid opcode: 0000 [#1] SMP
last sysfs file: /sys/module/ipv6/initstate
Modules linked in: sha256_generic sctp libcrc32c ipv6 dm_multipath
uinput 8139too i2c_piix4 8139cp mii i2c_core pcspkr virtio_net joydev
floppy virtio_blk virtio_pci [last unloaded: scsi_wait_scan]

Pid: 0, comm: swapper Not tainted 2.6.34-rc4 #15 /Bochs
EIP: 0060:[&lt;c044a2ef&gt;] EFLAGS: 00010286 CPU: 0
EIP is at add_timer+0xd/0x1b
EAX: cecbab14 EBX: 000000f0 ECX: c0957b1c EDX: 03595cf4
ESI: cecba800 EDI: cf276f00 EBP: c0957aa0 ESP: c0957aa0
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
Process swapper (pid: 0, ti=c0956000 task=c0988ba0 task.ti=c0956000)
Stack:
 c0957ae0 d1851214 c0ab62e4 c0ab5f26 0500ffff 00000004 00000005 00000004
&lt;0&gt; 00000000 d18694fd 00000004 1666b892 cecba800 cecba800 c0957b14
00000004
&lt;0&gt; c0957b94 d1851b11 ceda8b00 cecba800 cf276f00 00000001 c0957b14
000000d0
Call Trace:
 [&lt;d1851214&gt;] ? sctp_side_effects+0x607/0xdfc [sctp]
 [&lt;d1851b11&gt;] ? sctp_do_sm+0x108/0x159 [sctp]
 [&lt;d1863386&gt;] ? sctp_pname+0x0/0x1d [sctp]
 [&lt;d1861a56&gt;] ? sctp_primitive_ASCONF+0x36/0x3b [sctp]
 [&lt;d185657c&gt;] ? sctp_process_asconf_ack+0x2a4/0x2d3 [sctp]
 [&lt;d184e35c&gt;] ? sctp_sf_do_asconf_ack+0x1dd/0x2b4 [sctp]
 [&lt;d1851ac1&gt;] ? sctp_do_sm+0xb8/0x159 [sctp]
 [&lt;d1863334&gt;] ? sctp_cname+0x0/0x52 [sctp]
 [&lt;d1854377&gt;] ? sctp_assoc_bh_rcv+0xac/0xe1 [sctp]
 [&lt;d1858f0f&gt;] ? sctp_inq_push+0x2d/0x30 [sctp]
 [&lt;d186329d&gt;] ? sctp_rcv+0x797/0x82e [sctp]

Tested-by: Wei Yongjun &lt;yjwei@cn.fujitsu.com&gt;
Signed-off-by: Yuansong Qiao &lt;ysqiao@research.ait.ie&gt;
Signed-off-by: Shuaijun Zhang &lt;szhang@research.ait.ie&gt;
Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>sctp: Send user messages to the lower layer as one</title>
<updated>2009-09-04T22:20:57Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vladislav.yasevich@hp.com</email>
</author>
<published>2009-08-10T17:51:03Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=9c5c62be2f794c7cee533d856f9f34c3cf21ff1b'/>
<id>urn:sha1:9c5c62be2f794c7cee533d856f9f34c3cf21ff1b</id>
<content type='text'>
Currenlty, sctp breaks up user messages into fragments and
sends each fragment to the lower layer by itself.  This means
that for each fragment we go all the way down the stack
and back up.  This also discourages bundling of multiple
fragments when they can fit into a sigle packet (ex: due
to user setting a low fragmentation threashold).

We introduce a new command SCTP_CMD_SND_MSG and hand the
whole message down state machine.  The state machine and
the side-effect parser will cork the queue, add all chunks
from the message to the queue, and then un-cork the queue
thus causing the chunks to get transmitted.

Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
</content>
</entry>
<entry>
<title>sctp: Fix broken RTO-doubling for data retransmits</title>
<updated>2009-03-03T06:49:18Z</updated>
<author>
<name>Vlad Yasevich</name>
<email>vladislav.yasevich@hp.com</email>
</author>
<published>2009-03-02T09:46:14Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=7e99013a5043cacd375375c3efad35b57c3afdba'/>
<id>urn:sha1:7e99013a5043cacd375375c3efad35b57c3afdba</id>
<content type='text'>
Commit faee47cdbfe8d74a1573c2f81ea6dbb08d735be6
(sctp: Fix the RTO-doubling on idle-link heartbeats)
broke the RTO doubling for data retransmits.  If the
heartbeat was sent before the data T3-rtx time, the
the RTO will not double upon the T3-rtx expiration.
Distingish between the operations by passing an argument
to the function.

Additionally, Wei Youngjun pointed out that our treatment
of requested HEARTBEATS and timer HEARTBEATS is the same
wrt resetting congestion window.  That needs to be separated,
since user requested HEARTBEATS should not treat the link
as idle.

Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6</title>
<updated>2008-04-14T09:30:23Z</updated>
<author>
<name>David S. Miller</name>
<email>davem@davemloft.net</email>
</author>
<published>2008-04-14T09:30:23Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=df39e8ba56a788733d369068c7319e04b1da3cd5'/>
<id>urn:sha1:df39e8ba56a788733d369068c7319e04b1da3cd5</id>
<content type='text'>
Conflicts:

	drivers/net/ehea/ehea_main.c
	drivers/net/wireless/iwlwifi/Kconfig
	drivers/net/wireless/rt2x00/rt61pci.c
	net/ipv4/inet_timewait_sock.c
	net/ipv6/raw.c
	net/mac80211/ieee80211_sta.c
</content>
</entry>
<entry>
<title>[SCTP]: Fix protocol violation when receiving an error lenght INIT-ACK</title>
<updated>2008-04-13T01:39:34Z</updated>
<author>
<name>Gui Jianfeng</name>
<email>guijianfeng@cn.fujitsu.com</email>
</author>
<published>2008-04-13T01:39:34Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=f4ad85ca3ef8a1ede76c5020a28a8f4057b4d24f'/>
<id>urn:sha1:f4ad85ca3ef8a1ede76c5020a28a8f4057b4d24f</id>
<content type='text'>
When receiving an error length INIT-ACK during COOKIE-WAIT,
a 0-vtag ABORT will be responsed. This action violates the
protocol apparently. This patch achieves the following things.
1 If the INIT-ACK contains all the fixed parameters, use init-tag
  recorded from INIT-ACK as vtag.
2 If the INIT-ACK doesn't contain all the fixed parameters,
  just reflect its vtag.

Signed-off-by: Gui Jianfeng &lt;guijianfeng@cn.fujitsu.com&gt;
Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
<entry>
<title>[SCTP]: Remove sctp_add_cmd_sf wrapper bloat</title>
<updated>2008-03-28T00:54:29Z</updated>
<author>
<name>Ilpo Järvinen</name>
<email>ilpo.jarvinen@helsinki.fi</email>
</author>
<published>2008-03-28T00:54:29Z</published>
<link rel='alternate' type='text/html' href='https://git.amat.us/linux/commit/?id=bc09dff198e67a98a82c42000006b39f6d502031'/>
<id>urn:sha1:bc09dff198e67a98a82c42000006b39f6d502031</id>
<content type='text'>
With a was number of callsites sctp_add_cmd_sf wrapper bloats
kernel by some amount. Due to unlikely tracking allyesconfig,
with the initial result were around ~7kB (thus caught my
attention) while a non-debug config produced only ~2.3kB effect.

I (ij) proposed first a patch to uninline it but Vlad responded
with a patch that removed the only sctp_add_cmd call which is
wrapped by sctp_add_cmd_sf (I wasn't sure if I could do that).
I did minor cleanup to Vlad's patch.

Signed-off-by: Ilpo Järvinen &lt;ilpo.jarvinen@helsinki.fi&gt;
Signed-off-by: Vlad Yasevich &lt;vladislav.yasevich@hp.com&gt;
Signed-off-by: David S. Miller &lt;davem@davemloft.net&gt;
</content>
</entry>
</feed>
