1. 27 Nov, 2007 1 commit
  2. 26 Nov, 2007 4 commits
    • Adrian Bunk's avatar
      [IPV4]: Remove bogus ifdef mess in arp_process · 3660019e
      Adrian Bunk authored
      The #ifdef's in arp_process() were not only a mess, they were also wrong 
      in the CONFIG_NET_ETHERNET=n and (CONFIG_NETDEV_1000=y or 
      CONFIG_NETDEV_10000=y) cases.
      
      Since they are not required this patch removes them.
      
      Also removed are some #ifdef's around #include's that caused compile 
      errors after this change.
      Signed-off-by: default avatarAdrian Bunk <bunk@kernel.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      3660019e
    • Herbert Xu's avatar
      [SKBUFF]: Free old skb properly in skb_morph · 2d4baff8
      Herbert Xu authored
      The skb_morph function only freed the data part of the dst skb, but leaked
      the auxiliary data such as the netfilter fields.  This patch fixes this by
      moving the relevant parts from __kfree_skb to skb_release_all and calling
      it in skb_morph.
      
      It also makes kfree_skbmem static since it's no longer called anywhere else
      and it now no longer does skb_release_data.
      
      Thanks to Yasuyuki KOZAKAI for finding this problem and posting a patch for
      it.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      2d4baff8
    • Pavel Emelyanov's avatar
      [IPV4]: Fix memory leak in inet_hashtables.h when NUMA is on · 218ad12f
      Pavel Emelyanov authored
      The inet_ehash_locks_alloc() looks like this:
      
      #ifdef CONFIG_NUMA
      	if (size > PAGE_SIZE)
      		x = vmalloc(...);
      	else
      #endif
      		x = kmalloc(...);
      
      Unlike it, the inet_ehash_locks_alloc() looks like this:
      
      #ifdef CONFIG_NUMA
      	if (size > PAGE_SIZE)
      		vfree(x);
      	else
      #else
      		kfree(x);
      #endif
      
      The error is obvious - if the NUMA is on and the size
      is less than the PAGE_SIZE we leak the pointer (kfree is
      inside the #else branch).
      
      Compiler doesn't warn us because after the kfree(x) there's
      a "x = NULL" assignment, so here's another (minor?) bug: we 
      don't set x to NULL under certain circumstances.
      
      Boring explanation, I know... Patch explains it better.
      Signed-off-by: default avatarPavel Emelyanov <xemul@openvz.org>
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      218ad12f
    • Herbert Xu's avatar
      [IPSEC]: Temporarily remove locks around copying of non-atomic fields · 8053fc3d
      Herbert Xu authored
      The change 050f009e
      
      	[IPSEC]: Lock state when copying non-atomic fields to user-space
      
      caused a regression.
      
      Ingo Molnar reports that it causes a potential dead-lock found by the
      lock validator as it tries to take x->lock within xfrm_state_lock while
      numerous other sites take the locks in opposite order.
      
      For 2.6.24, the best fix is to simply remove the added locks as that puts
      us back in the same state as we've been in for years.  For later kernels
      a proper fix would be to reverse the locking order for every xfrm state
      user such that if x->lock is taken together with xfrm_state_lock then
      it is to be taken within it.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      8053fc3d
  3. 23 Nov, 2007 2 commits
  4. 22 Nov, 2007 5 commits
  5. 21 Nov, 2007 7 commits
  6. 20 Nov, 2007 19 commits
  7. 19 Nov, 2007 2 commits
    • Herbert Xu's avatar
      [TCP]: Fix TCP header misalignment · 21df56c6
      Herbert Xu authored
      Indeed my previous change to alloc_pskb has made it possible
      for the TCP header to be misaligned iff the MTU is not a multiple
      of 4 (and less than a page).  So I suspect the optimised IPsec
      MTU calculation is giving you just such an MTU :)
      
      This patch fixes it by changing alloc_pskb to make sure that
      the size is at least 32-bit aligned.  This does not cause the
      problem fixed by the previous patch because max_header is always
      32-bit aligned which means that in the SG/NOTSO case this will
      be a no-op.
      
      I thought about putting this in the callers but all the current
      callers are from TCP.  If and when we get a non-TCP caller we
      can always create a TCP wrapper for this function and move the
      alignment over there.
      Signed-off-by: default avatarHerbert Xu <herbert@gondor.apana.org.au>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      21df56c6
    • Eric Dumazet's avatar
      [NET]: Corrects a bug in ip_rt_acct_read() · 483b23ff
      Eric Dumazet authored
      It seems that stats of cpu 0 are counted twice, since
      for_each_possible_cpu() is looping on all possible cpus, including 0
      
      Before percpu conversion of ip_rt_acct, we should also remove the
      assumption that CPU 0 is online (or even possible)
      Signed-off-by: default avatarEric Dumazet <dada1@cosmosbay.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      483b23ff