1. 15 8月, 2012 9 次提交
  2. 16 7月, 2012 1 次提交
  3. 12 7月, 2012 1 次提交
  4. 11 5月, 2012 1 次提交
  5. 09 3月, 2012 1 次提交
  6. 12 12月, 2011 1 次提交
  7. 06 6月, 2011 1 次提交
  8. 02 6月, 2011 2 次提交
  9. 08 5月, 2011 1 次提交
  10. 20 4月, 2011 1 次提交
  11. 24 9月, 2010 1 次提交
  12. 27 8月, 2010 1 次提交
  13. 01 5月, 2010 1 次提交
  14. 29 4月, 2010 1 次提交
    • W
      sctp: avoid irq lock inversion while call sk->sk_data_ready() · 561b1733
      Wei Yongjun 提交于
      sk->sk_data_ready() of sctp socket can be called from both BH and non-BH
      contexts, but the default sk->sk_data_ready(), sock_def_readable(), can
      not be used in this case. Therefore, we have to make a new function
      sctp_data_ready() to grab sk->sk_data_ready() with BH disabling.
      
      =========================================================
      [ INFO: possible irq lock inversion dependency detected ]
      2.6.33-rc6 #129
      ---------------------------------------------------------
      sctp_darn/1517 just changed the state of lock:
       (clock-AF_INET){++.?..}, at: [<c06aab60>] sock_def_readable+0x20/0x80
      but this lock took another, SOFTIRQ-unsafe lock in the past:
       (slock-AF_INET){+.-...}
      
      and interrupts could create inverse lock ordering between them.
      
      other info that might help us debug this:
      1 lock held by sctp_darn/1517:
       #0:  (sk_lock-AF_INET){+.+.+.}, at: [<cdfe363d>] sctp_sendmsg+0x23d/0xc00 [sctp]
      Signed-off-by: NWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      561b1733
  15. 22 3月, 2010 1 次提交
  16. 04 11月, 2009 1 次提交
  17. 05 9月, 2009 1 次提交
    • V
      sctp: Fix SCTP_MAXSEG socket option to comply to spec. · f68b2e05
      Vlad Yasevich 提交于
      We had a bug that we never stored the user-defined value for
      MAXSEG when setting the value on an association.  Thus future
      PMTU events ended up re-writing the frag point and increasing
      it past user limit.  Additionally, when setting the option on
      the socket/endpoint, we effect all current associations, which
      is against spec.
      
      Now, we store the user 'maxseg' value along with the computed
      'frag_point'.  We inherit 'maxseg' from the socket at association
      creation and use it as an upper limit for 'frag_point' when its
      set.
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      f68b2e05
  18. 24 6月, 2009 1 次提交
    • H
      net: Move rx skb_orphan call to where needed · d55d87fd
      Herbert Xu 提交于
      In order to get the tun driver to account packets, we need to be
      able to receive packets with destructors set.  To be on the safe
      side, I added an skb_orphan call for all protocols by default since
      some of them (IP in particular) cannot handle receiving packets
      destructors properly.
      
      Now it seems that at least one protocol (CAN) expects to be able
      to pass skb->sk through the rx path without getting clobbered.
      
      So this patch attempts to fix this properly by moving the skb_orphan
      call to where it's actually needed.  In particular, I've added it
      to skb_set_owner_[rw] which is what most users of skb->destructor
      call.
      
      This is actually an improvement for tun too since it means that
      we only give back the amount charged to the socket when the skb
      is passed to another socket that will also be charged accordingly.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: NOliver Hartkopp <olver@hartkopp.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      d55d87fd
  19. 22 3月, 2009 1 次提交
  20. 16 2月, 2009 1 次提交
  21. 26 11月, 2008 1 次提交
  22. 31 10月, 2008 1 次提交
  23. 30 10月, 2008 1 次提交
  24. 29 10月, 2008 1 次提交
  25. 17 10月, 2008 1 次提交
  26. 23 9月, 2008 1 次提交
  27. 17 6月, 2008 1 次提交
  28. 10 5月, 2008 1 次提交
  29. 22 3月, 2008 1 次提交
    • D
      [SCTP]: Fix build warnings with IPV6 disabled. · 1233823b
      David S. Miller 提交于
      Introduced by 270637ab
      ("[SCTP]: Fix a race between module load and protosw access")
      
      Reported by Gabriel C:
      
      In file included from net/sctp/sm_statetable.c:50:
      include/net/sctp/sctp.h: In function 'sctp_v6_pf_init':
      include/net/sctp/sctp.h:392: warning: 'return' with a value, in function returning void
      In file included from net/sctp/sm_statefuns.c:62:
      include/net/sctp/sctp.h: In function 'sctp_v6_pf_init':
      include/net/sctp/sctp.h:392: warning: 'return' with a value, in function returning void
       ...
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      1233823b
  30. 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
  31. 01 3月, 2008 1 次提交