1. 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
  2. 20 7月, 2008 1 次提交
  3. 19 7月, 2008 3 次提交
  4. 18 6月, 2008 1 次提交
  5. 17 6月, 2008 1 次提交
  6. 05 6月, 2008 3 次提交
  7. 10 5月, 2008 1 次提交
  8. 13 4月, 2008 1 次提交
  9. 10 4月, 2008 1 次提交
  10. 04 4月, 2008 4 次提交
  11. 26 3月, 2008 2 次提交
  12. 21 3月, 2008 1 次提交
    • V
      [SCTP]: Fix a race between module load and protosw access · 270637ab
      Vlad Yasevich 提交于
      There is a race is SCTP between the loading of the module
      and the access by the socket layer to the protocol functions.
      In particular, a list of addresss that SCTP maintains is
      not initialized prior to the registration with the protosw.
      Thus it is possible for a user application to gain access
      to SCTP functions before everything has been initialized.
      The problem shows up as odd crashes during connection
      initializtion when we try to access the SCTP address list.
      
      The solution is to refactor how we do registration and
      initialize the lists prior to registering with the protosw.
      Care must be taken since the address list initialization
      depends on some other pieces of SCTP initialization.  Also
      the clean-up in case of failure now also needs to be refactored.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Acked-by: NSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      270637ab
  13. 18 3月, 2008 1 次提交
  14. 12 3月, 2008 1 次提交
  15. 06 3月, 2008 2 次提交
  16. 29 2月, 2008 2 次提交
  17. 05 2月, 2008 1 次提交
  18. 29 1月, 2008 5 次提交
  19. 10 11月, 2007 1 次提交
  20. 08 11月, 2007 1 次提交
  21. 01 11月, 2007 1 次提交
  22. 17 10月, 2007 1 次提交
  23. 11 10月, 2007 4 次提交