1. 30 6月, 2009 1 次提交
  2. 03 6月, 2009 1 次提交
  3. 28 4月, 2009 1 次提交
  4. 22 3月, 2009 1 次提交
  5. 16 2月, 2009 2 次提交
  6. 01 2月, 2009 1 次提交
  7. 23 1月, 2009 1 次提交
    • V
      sctp: Properly timestamp outgoing data chunks for rtx purposes · 759af00e
      Vlad Yasevich 提交于
      Recent changes to the retransmit code exposed a long standing
      bug where it was possible for a chunk to be time stamped
      after the retransmit timer was reset.  This caused a rare
      situation where the retrnamist timer has expired, but
      nothing was marked for retrnasmission because all of
      timesamps on data were less then 1 rto ago.  As result,
      the timer was never restarted since nothing was retransmitted,
      and this resulted in a hung association that did couldn't
      complete the data transfer.  The solution is to timestamp
      the chunk when it's added to the packet for transmission
      purposes.  After the packet is trsnmitted the rtx timer
      is restarted.  This guarantees that when the timer expires,
      there will be data to retransmit.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      759af00e
  8. 01 10月, 2008 1 次提交
  9. 18 9月, 2008 1 次提交
  10. 04 8月, 2008 1 次提交
    • H
      sctp: Drop ipfargok in sctp_xmit function · f880374c
      Herbert Xu 提交于
      The ipfragok flag controls whether the packet may be fragmented
      either on the local host on beyond.  The latter is only valid on
      IPv4.
      
      In fact, we never want to do the latter even on IPv4 when PMTU is
      enabled.  This is because even though we can't fragment packets
      within SCTP due to the prtocol's inherent faults, we can still
      fragment it at IP layer.  By setting the DF bit we will improve
      the PMTU process.
      
      RFC 2960 only says that we SHOULD clear the DF bit in this case,
      so we're compliant even if we set the DF bit.  In fact RFC 4960
      no longer has this statement.
      
      Once we make this change, we only need to control the local
      fragmentation.  There is already a bit in the skb which controls
      that, local_df.  So this patch sets that instead of using the
      ipfragok argument.
      
      The only complication is that there isn't a struct sock object
      per transport, so for IPv4 we have to resort to changing the
      pmtudisc field for every packet.  This should be safe though
      as the protocol is single-threaded.
      
      Note that after this patch we can remove ipfragok from the rest
      of the stack too.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f880374c
  11. 19 7月, 2008 1 次提交
  12. 17 7月, 2008 1 次提交
  13. 20 6月, 2008 1 次提交
    • V
      sctp: Follow security requirement of responding with 1 packet · 2e3216cd
      Vlad Yasevich 提交于
      RFC 4960, Section 11.4. Protection of Non-SCTP-Capable Hosts
      
      When an SCTP stack receives a packet containing multiple control or
      DATA chunks and the processing of the packet requires the sending of
      multiple chunks in response, the sender of the response chunk(s) MUST
      NOT send more than one packet.  If bundling is supported, multiple
      response chunks that fit into a single packet MAY be bundled together
      into one single response packet.  If bundling is not supported, then
      the sender MUST NOT send more than one response chunk and MUST
      discard all other responses.  Note that this rule does NOT apply to a
      SACK chunk, since a SACK chunk is, in itself, a response to DATA and
      a SACK does not require a response of more DATA.
      
      We implement this by not servicing our outqueue until we reach the end
      of the packet.  This enables maximum bundling.  We also identify
      'response' chunks and make sure that we only send 1 packet when sending
      such chunks.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      2e3216cd
  14. 05 6月, 2008 1 次提交
  15. 06 3月, 2008 1 次提交
  16. 05 2月, 2008 1 次提交
  17. 29 1月, 2008 1 次提交
  18. 11 10月, 2007 2 次提交
  19. 26 4月, 2007 1 次提交
  20. 11 2月, 2007 1 次提交
  21. 30 9月, 2006 1 次提交
  22. 18 6月, 2006 1 次提交
  23. 03 2月, 2006 1 次提交
  24. 04 1月, 2006 1 次提交
  25. 09 7月, 2005 1 次提交
  26. 29 4月, 2005 1 次提交
  27. 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