1. 23 1月, 2012 2 次提交
    • G
      net: introduce res_counter_charge_nofail() for socket allocations · 0e90b31f
      Glauber Costa 提交于
      There is a case in __sk_mem_schedule(), where an allocation
      is beyond the maximum, but yet we are allowed to proceed.
      It happens under the following condition:
      
      	sk->sk_wmem_queued + size >= sk->sk_sndbuf
      
      The network code won't revert the allocation in this case,
      meaning that at some point later it'll try to do it. Since
      this is never communicated to the underlying res_counter
      code, there is an inbalance in res_counter uncharge operation.
      
      I see two ways of fixing this:
      
      1) storing the information about those allocations somewhere
         in memcg, and then deducting from that first, before
         we start draining the res_counter,
      2) providing a slightly different allocation function for
         the res_counter, that matches the original behavior of
         the network code more closely.
      
      I decided to go for #2 here, believing it to be more elegant,
      since #1 would require us to do basically that, but in a more
      obscure way.
      Signed-off-by: NGlauber Costa <glommer@parallels.com>
      Cc: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
      Cc: Johannes Weiner <hannes@cmpxchg.org>
      Cc: Michal Hocko <mhocko@suse.cz>
      CC: Tejun Heo <tj@kernel.org>
      CC: Li Zefan <lizf@cn.fujitsu.com>
      CC: Laurent Chavey <chavey@google.com>
      Acked-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      0e90b31f
    • P
      pktgen: Fix unsigned function that is returning negative vals · bf0813bd
      Paul Gortmaker 提交于
      Every call to num_args() immediately checks the return value for
      less than zero, as it will return -EFAULT for a failed get_user()
      call.  So it makes no sense for the function to be declared as an
      unsigned long.
      Signed-off-by: NPaul Gortmaker <paul.gortmaker@windriver.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bf0813bd
  2. 18 1月, 2012 2 次提交
  3. 17 1月, 2012 3 次提交
  4. 13 1月, 2012 1 次提交
  5. 10 1月, 2012 3 次提交
  6. 09 1月, 2012 1 次提交
  7. 08 1月, 2012 2 次提交
  8. 06 1月, 2012 1 次提交
  9. 05 1月, 2012 2 次提交
  10. 31 12月, 2011 1 次提交
  11. 29 12月, 2011 1 次提交
  12. 25 12月, 2011 1 次提交
  13. 23 12月, 2011 2 次提交
  14. 22 12月, 2011 1 次提交
  15. 20 12月, 2011 1 次提交
  16. 17 12月, 2011 6 次提交
  17. 14 12月, 2011 2 次提交
  18. 13 12月, 2011 3 次提交
  19. 12 12月, 2011 1 次提交
  20. 10 12月, 2011 1 次提交
  21. 09 12月, 2011 2 次提交
  22. 07 12月, 2011 1 次提交