1. 27 12月, 2013 1 次提交
  2. 07 12月, 2013 1 次提交
  3. 10 8月, 2013 1 次提交
  4. 25 7月, 2013 1 次提交
  5. 15 8月, 2012 2 次提交
  6. 08 7月, 2011 1 次提交
    • T
      sctp: Enforce retransmission limit during shutdown · f8d96052
      Thomas Graf 提交于
      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: NThomas Graf <tgraf@infradead.org>
      Acked-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f8d96052
  7. 22 4月, 2011 1 次提交
  8. 20 4月, 2011 1 次提交
  9. 27 8月, 2010 1 次提交
  10. 03 6月, 2009 1 次提交
  11. 23 10月, 2008 2 次提交
  12. 01 10月, 2008 1 次提交
    • W
      sctp: Fix to start T5-shutdown-guard timer while enter SHUTDOWN-SENT state · 536428a9
      Wei Yongjun 提交于
      RFC 4960: Section 9.2
      The sender of the SHUTDOWN MAY also start an overall guard timer
      'T5-shutdown-guard' to bound the overall time for the shutdown
      sequence.  At the expiration of this timer, the sender SHOULD abort
      the association by sending an ABORT chunk.  If the 'T5-shutdown-
      guard' timer is used, it SHOULD be set to the recommended value of 5
      times 'RTO.Max'.
      
      The timer 'T5-shutdown-guard' is used to counter the overall time
      for shutdown sequence, and it's start by the sender of the SHUTDOWN.
      So timer 'T5-shutdown-guard' should be start when we send the first
      SHUTDOWN chunk and enter the SHUTDOWN-SENT state, not start when we
      receipt of the SHUTDOWN primitive and enter SHUTDOWN-PENDING state.
      
      If 'T5-shutdown-guard' timer is start at SHUTDOWN-PENDING state, the
      association may be ABORT while data is still transmitting.
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      536428a9
  13. 05 2月, 2008 1 次提交
  14. 29 1月, 2008 1 次提交
  15. 11 10月, 2007 1 次提交
  16. 26 9月, 2007 1 次提交
  17. 04 6月, 2007 1 次提交
  18. 26 4月, 2007 1 次提交
  19. 11 2月, 2007 1 次提交
  20. 24 1月, 2007 1 次提交
  21. 03 12月, 2006 1 次提交
  22. 06 5月, 2006 1 次提交
  23. 21 6月, 2005 1 次提交
  24. 17 4月, 2005 1 次提交
    • L
      Linux-2.6.12-rc2 · 1da177e4
      Linus Torvalds 提交于
      Initial git repository build. I'm not bothering with the full history,
      even though we have it. We can create a separate "historical" git
      archive of that later if we want to, and in the meantime it's about
      3.2GB when imported into git - space that would just make the early
      git days unnecessarily complicated, when we don't have a lot of good
      infrastructure for it.
      
      Let it rip!
      1da177e4