1. 27 1月, 2010 10 次提交
  2. 26 1月, 2010 1 次提交
  3. 23 1月, 2010 4 次提交
  4. 21 1月, 2010 2 次提交
  5. 20 1月, 2010 3 次提交
  6. 19 1月, 2010 3 次提交
    • O
      ipv4: allow warming up the ARP cache with request type gratuitous ARP · 6d955180
      Octavian Purdila 提交于
      If the per device ARP_ACCEPT option is enable, currently we only allow
      creating new ARP cache entries for response type gratuitous ARP.
      
      Allowing gratuitous ARP to create new ARP entries (not only to update
      existing ones) is useful when we want to avoid unnecessary delays for
      the first packet of a stream.
      
      This patch allows request type gratuitous ARP to create new ARP cache
      entries as well. This is useful when we want to populate the ARP cache
      entries for a large number of hosts on the same LAN.
      Signed-off-by: NOctavian Purdila <opurdila@ixiacom.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      6d955180
    • N
      dccp: fix dccp rmmod when kernel configured to use slub · de4ef86c
      Neil Horman 提交于
      Hey all-
      	I was tinkering with dccp recently and noticed that I BUG halted the
      kernel when I rmmod-ed the dccp module.  The bug halt occured because the page
      that I passed to kfree failed the PageCompound and PageSlab test in the slub
      implementation of kfree.  I tracked the problem down to the following set of
      events:
      
      1) dccp, unlike all other uses of kmem_cache_create, allocates a string
      dynamically when registering a slab cache.  This allocated string is freed when
      the cache is destroyed.
      
      2) Normally, (1) is not an issue, but when Slub is in use, it is possible that
      caches are 'merged'.  This process causes multiple caches of simmilar
      configuration to use the same cache data structure.  When this happens, the new
      name of the cache is effectively dropped.
      
      3) (2) results in kmem_cache_name returning an ambigous value (i.e.
      ccid_kmem_cache_destroy, which uses this fuction to retrieve the name pointer
      for freeing), is no longer guaranteed that the string it assigned is what is
      returned.
      
      4) If such merge event occurs, ccid_kmem_cache_destroy frees the wrong pointer,
      which trips over the BUG in the slub implementation of kfree (since its likely
      not a slab allocation, but rather a pointer into the static string table
      section.
      
      So, what to do about this.  At first blush this is pretty clearly a leak in the
      information that slub owns, and as such a slub bug.  Unfortunately, theres no
      really good way to fix it, without exposing slub specific implementation details
      to the generic slab interface.  Also, even if we could fix this in slub cleanly,
      I think the RCU free option would force us to do lots of string duplication, not
      only in slub, but in every slab allocator.  As such, I'd like to propose this
      solution.  Basically, I just move the storage for the kmem cache name to the
      ccid_operations structure.  In so doing, we don't have to do the kstrdup or
      kfree when we allocate/free the various caches for dccp, and so we avoid the
      problem, by storing names with static memory, rather than heap, the way all
      other calls to kmem_cache_create do.
      
      I've tested this out myself here, and it solves the problem quite well.
      Signed-off-by: NNeil Horman <nhorman@tuxdriver.com>
      Acked-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      de4ef86c
    • B
      mac80211: fix sign error in pid controller · e850f68b
      Bob Copeland 提交于
      While testing the pid rate controller in mac80211_hwsim, I noticed
      that once the controller reached 54 Mbit rates, it would fail to
      lower the rate when necessary.  The debug log shows:
      
      1945 186786 pf_sample 50 3534 3577 50
      
      My interpretation is that the fixed point scaling of the target
      error value (pf) is incorrect: the error value of 50 compared to
      a target of 14 case should result in a scaling value of
      (14-50) = -36 * 256 or -9216, but instead it is (14 * 256)-50, or
      3534.
      
      Correct this by doing fixed point scaling after subtraction.
      Signed-off-by: NBob Copeland <me@bobcopeland.com>
      Acked-by: NStefano Brivio <stefano.brivio@polimi.it>
      Acked-by: NMattias Nissler <mattias.nissler@gmx.de>
      Signed-off-by: NJohn W. Linville <linville@tuxdriver.com>
      e850f68b
  7. 18 1月, 2010 3 次提交
  8. 16 1月, 2010 6 次提交
  9. 15 1月, 2010 7 次提交
  10. 14 1月, 2010 1 次提交