1. 29 3月, 2008 1 次提交
  2. 24 3月, 2008 1 次提交
  3. 06 3月, 2008 2 次提交
  4. 29 2月, 2008 2 次提交
  5. 20 2月, 2008 1 次提交
  6. 07 2月, 2008 1 次提交
  7. 05 2月, 2008 2 次提交
  8. 29 1月, 2008 3 次提交
    • H
      [NET] CORE: Introducing new memory accounting interface. · 3ab224be
      Hideo Aoki 提交于
      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: NTakahiro Yasui <tyasui@redhat.com>
      Signed-off-by: NHideo Aoki <haoki@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      3ab224be
    • V
    • P
      [NET]: Name magic constants in sock_wake_async() · 8d8ad9d7
      Pavel Emelyanov 提交于
      The sock_wake_async() performs a bit different actions
      depending on "how" argument. Unfortunately this argument
      ony has numerical magic values.
      
      I propose to give names to their constants to help people
      reading this function callers understand what's going on
      without looking into this function all the time.
      
      I suppose this is 2.6.25 material, but if it's not (or the
      naming seems poor/bad/awful), I can rework it against the
      current net-2.6 tree.
      Signed-off-by: NPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8d8ad9d7
  9. 07 12月, 2007 2 次提交
  10. 10 11月, 2007 1 次提交
  11. 08 11月, 2007 1 次提交
  12. 07 11月, 2007 1 次提交
  13. 15 10月, 2007 1 次提交
  14. 11 10月, 2007 5 次提交
  15. 17 9月, 2007 2 次提交
  16. 31 8月, 2007 2 次提交
  17. 01 8月, 2007 5 次提交
  18. 19 7月, 2007 1 次提交
  19. 06 7月, 2007 2 次提交
  20. 26 6月, 2007 1 次提交
    • Z
      SCTP: lock_sock_nested in sctp_sock_migrate · 5131a184
      Zach Brown 提交于
      sctp_sock_migrate() grabs the socket lock on a newly allocated socket while
      holding the socket lock on an old socket.  lockdep worries that this might
      be a recursive lock attempt.
      
       task/3026 is trying to acquire lock:
        (sk_lock-AF_INET){--..}, at: [<ffffffff88105b8c>] sctp_sock_migrate+0x2e3/0x327 [sctp]
       but task is already holding lock:
        (sk_lock-AF_INET){--..}, at: [<ffffffff8810891f>] sctp_accept+0xdf/0x1e3 [sctp]
      
      This patch tells lockdep that this locking is safe by using
      lock_sock_nested().
      Signed-off-by: NZach Brown <zach.brown@oracle.com>
      Signed-off-by: NVlad Yasevich <vladislav.yasevich@hp.com>
      5131a184
  21. 19 6月, 2007 2 次提交
  22. 14 6月, 2007 1 次提交