1. 27 Feb, 2009 5 commits
  2. 22 Feb, 2009 1 commit
    • Eric W. Biederman's avatar
      netns: Remove net_alive · ce16c533
      Eric W. Biederman authored
      It turns out that net_alive is unnecessary, and the original problem
      that led to it being added was simply that the icmp code thought
      it was a network device and wound up being unable to handle packets
      while there were still packets in the network namespace.
      
      Now that icmp and tcp have been fixed to properly register themselves
      this problem is no longer present and we have a stronger guarantee
      that packets will not arrive in a network namespace then that provided
      by net_alive in netif_receive_skb.  So remove net_alive allowing
      packet reception run a little faster.
      
      Additionally document the strong reason why network namespace cleanup
      is safe so that if something happens again someone else will have
      a chance of figuring it out.
      Signed-off-by: default avatarEric W. Biederman <ebiederm@aristanetworks.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      ce16c533
  3. 18 Feb, 2009 1 commit
  4. 17 Feb, 2009 1 commit
    • David S. Miller's avatar
      net: Kill skb_truesize_check(), it only catches false-positives. · 92a0acce
      David S. Miller authored
      A long time ago we had bugs, primarily in TCP, where we would modify
      skb->truesize (for TSO queue collapsing) in ways which would corrupt
      the socket memory accounting.
      
      skb_truesize_check() was added in order to try and catch this error
      more systematically.
      
      However this debugging check has morphed into a Frankenstein of sorts
      and these days it does nothing other than catch false-positives.
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      92a0acce
  5. 16 Feb, 2009 4 commits
  6. 15 Feb, 2009 2 commits
  7. 14 Feb, 2009 1 commit
  8. 13 Feb, 2009 5 commits
  9. 12 Feb, 2009 1 commit
    • Andrew Morton's avatar
      net: don't use in_atomic() in gfp_any() · 99709372
      Andrew Morton authored
      The problem is that in_atomic() will return false inside spinlocks if
      CONFIG_PREEMPT=n.  This will lead to deadlockable GFP_KERNEL allocations
      from spinlocked regions.
      
      Secondly, if CONFIG_PREEMPT=y, this bug solves itself because networking
      will instead use GFP_ATOMIC from this callsite.  Hence we won't get the
      might_sleep() debugging warnings which would have informed us of the buggy
      callsites.
      
      Solve both these problems by switching to in_interrupt().  Now, if someone
      runs a gfp_any() allocation from inside spinlock we will get the warning
      if CONFIG_PREEMPT=y.
      
      I reviewed all callsites and most of them were too complex for my little
      brain and none of them documented their interface requirements.  I have no
      idea what this patch will do.
      Signed-off-by: default avatarAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      99709372
  10. 09 Feb, 2009 1 commit
  11. 04 Feb, 2009 1 commit
  12. 01 Feb, 2009 2 commits
  13. 29 Jan, 2009 15 commits