Skip to content
Snippets Groups Projects
  1. Aug 15, 2012
  2. Jul 16, 2012
  3. Jul 12, 2012
  4. May 11, 2012
  5. Mar 08, 2012
  6. Dec 12, 2011
  7. Jun 05, 2011
  8. Jun 02, 2011
  9. May 08, 2011
  10. Apr 20, 2011
  11. Sep 23, 2010
  12. Aug 26, 2010
  13. May 01, 2010
  14. Apr 28, 2010
    • Wei Yongjun's avatar
      sctp: avoid irq lock inversion while call sk->sk_data_ready() · 561b1733
      Wei Yongjun authored
      
      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: default avatarWei Yongjun <yjwei@cn.fujitsu.com>
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      561b1733
  15. Mar 22, 2010
  16. Nov 04, 2009
  17. Sep 05, 2009
    • Vlad Yasevich's avatar
      sctp: Fix SCTP_MAXSEG socket option to comply to spec. · f68b2e05
      Vlad Yasevich authored
      
      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: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      f68b2e05
  18. Jun 24, 2009
    • Herbert Xu's avatar
      net: Move rx skb_orphan call to where needed · d55d87fd
      Herbert Xu authored
      
      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: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Tested-by: default avatarOliver Hartkopp <olver@hartkopp.net>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      d55d87fd
  19. Mar 21, 2009
  20. Feb 16, 2009
  21. Nov 26, 2008
  22. Oct 31, 2008
  23. Oct 29, 2008
  24. Oct 16, 2008
  25. Sep 23, 2008
  26. Jun 17, 2008
  27. May 10, 2008
  28. Mar 21, 2008
    • David S. Miller's avatar
      [SCTP]: Fix build warnings with IPV6 disabled. · 1233823b
      David S. Miller authored
      
      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: default avatarDavid S. Miller <davem@davemloft.net>
      1233823b
  29. Mar 20, 2008
    • Vlad Yasevich's avatar
      [SCTP]: Fix a race between module load and protosw access · 270637ab
      Vlad Yasevich authored
      
      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: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      Acked-by: default avatarSridhar Samudrala <sri@us.ibm.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      270637ab
  30. Feb 29, 2008
  31. Feb 05, 2008
  32. Jan 29, 2008
    • Hideo Aoki's avatar
      [NET] CORE: Introducing new memory accounting interface. · 3ab224be
      Hideo Aoki authored
      
      This patch introduces new memory accounting functions for each network
      protocol. Most of them are renamed from memory accounting functions
      for stream protocols. At the same time, some stream memory accounting
      functions are removed since other functions do same thing.
      
      Renaming:
      	sk_stream_free_skb()		->	sk_wmem_free_skb()
      	__sk_stream_mem_reclaim()	->	__sk_mem_reclaim()
      	sk_stream_mem_reclaim()		->	sk_mem_reclaim()
      	sk_stream_mem_schedule 		->    	__sk_mem_schedule()
      	sk_stream_pages()      		->	sk_mem_pages()
      	sk_stream_rmem_schedule()	->	sk_rmem_schedule()
      	sk_stream_wmem_schedule()	->	sk_wmem_schedule()
      	sk_charge_skb()			->	sk_mem_charge()
      
      Removeing
      	sk_stream_rfree():	consolidates into sock_rfree()
      	sk_stream_set_owner_r(): consolidates into skb_set_owner_r()
      	sk_stream_mem_schedule()
      
      The following functions are added.
          	sk_has_account(): check if the protocol supports accounting
      	sk_mem_uncharge(): do the opposite of sk_mem_charge()
      
      In addition, to achieve consolidation, updating sk_wmem_queued is
      removed from sk_mem_charge().
      
      Next, to consolidate memory accounting functions, this patch adds
      memory accounting calls to network core functions. Moreover, present
      memory accounting call is renamed to new accounting call.
      
      Finally we replace present memory accounting calls with new interface
      in TCP and SCTP.
      
      Signed-off-by: default avatarTakahiro Yasui <tyasui@redhat.com>
      Signed-off-by: default avatarHideo Aoki <haoki@redhat.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      3ab224be
  33. Jan 28, 2008
  34. Nov 09, 2007
  35. Nov 07, 2007
    • Vlad Yasevich's avatar
      SCTP: Fix difference cases of retransmit. · b6157d8e
      Vlad Yasevich authored
      
      Commit d0ce9291 broke several retransmit
      cases including fast retransmit.  The reason is that we should
      only delay by rto while doing retranmists as a result of a timeout.
      Retransmit as a result of path mtu discover, fast retransmit, or
      other evernts that should trigger immidiate retransmissions got broken.
      
      Also, since rto is doubled prior to marking of packets elegable for
      retransmission, we never marked correct chunks anyway.
      
      The fix is provide a reason for a given retransmission so that we
      can mark chunks appropriately and to save the old rto value to do
      comparisons against.
      
      All regressions tests passed with this code.
      
      Spotted by Wei Yongjun <yjwei@cn.fujitsu.com>
      
      Signed-off-by: default avatarVlad Yasevich <vladislav.yasevich@hp.com>
      b6157d8e
Loading