1. 15 2月, 2007 1 次提交
    • T
      [PATCH] remove many unneeded #includes of sched.h · cd354f1a
      Tim Schmielau 提交于
      After Al Viro (finally) succeeded in removing the sched.h #include in module.h
      recently, it makes sense again to remove other superfluous sched.h includes.
      There are quite a lot of files which include it but don't actually need
      anything defined in there.  Presumably these includes were once needed for
      macros that used to live in sched.h, but moved to other header files in the
      course of cleaning it up.
      
      To ease the pain, this time I did not fiddle with any header files and only
      removed #includes from .c-files, which tend to cause less trouble.
      
      Compile tested against 2.6.20-rc2 and 2.6.20-rc2-mm2 (with offsets) on alpha,
      arm, i386, ia64, mips, powerpc, and x86_64 with allnoconfig, defconfig,
      allmodconfig, and allyesconfig as well as a few randconfigs on x86_64 and all
      configs in arch/arm/configs on arm.  I also checked that no new warnings were
      introduced by the patch (actually, some warnings are removed that were emitted
      by unnecessarily included header files).
      Signed-off-by: NTim Schmielau <tim@physik3.uni-rostock.de>
      Acked-by: NRussell King <rmk+kernel@arm.linux.org.uk>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      cd354f1a
  2. 13 2月, 2007 1 次提交
  3. 12 2月, 2007 1 次提交
  4. 11 2月, 2007 1 次提交
  5. 09 2月, 2007 2 次提交
    • A
      [NET]: user of the jiffies rounding code: Networking · f5a6e01c
      Arjan van de Ven 提交于
      This patch introduces users of the round_jiffies() function in the
      networking code.
      
      These timers all were of the "about once a second" or "about once
      every X seconds" variety and several showed up in the "what wakes the
      cpu up" profiles that the tickless patches provide.  Some timers are
      highly dynamic based on network load; but even on low activity systems
      they still show up so the rounding is done only in cases of low
      activity, allowing higher frequency timers in the high activity case.
      
      The various hardware watchdogs are an obvious case; they run every 2
      seconds but aren't otherwise specific of exactly when they need to
      run.
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      f5a6e01c
    • P
      [NETLINK]: Don't BUG on undersized allocations · 26932566
      Patrick McHardy 提交于
      Currently netlink users BUG when the allocated skb for an event
      notification is undersized. While this is certainly a kernel bug,
      its not critical and crashing the kernel is too drastic, especially
      when considering that these errors have appeared multiple times in
      the past and it BUGs even if no listeners are present.
      
      This patch replaces BUG by WARN_ON and changes the notification
      functions to inform potential listeners of undersized allocations
      using a unique error code (EMSGSIZE).
      Signed-off-by: NPatrick McHardy <kaber@trash.net>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      26932566
  6. 09 12月, 2006 1 次提交
  7. 08 12月, 2006 1 次提交
  8. 03 12月, 2006 2 次提交
  9. 04 10月, 2006 1 次提交
  10. 29 9月, 2006 1 次提交
  11. 23 9月, 2006 10 次提交
  12. 18 9月, 2006 1 次提交
  13. 03 8月, 2006 1 次提交
  14. 01 7月, 2006 1 次提交
  15. 13 5月, 2006 1 次提交
    • S
      [NEIGH]: Fix IP-over-ATM and ARP interaction. · bd89efc5
      Simon Kelley 提交于
      The classical IP over ATM code maintains its own IPv4 <-> <ATM stuff>
      ARP table, using the standard neighbour-table code. The
      neigh_table_init function adds this neighbour table to a linked list
      of all neighbor tables which is used by the functions neigh_delete()
      neigh_add() and neightbl_set(), all called by the netlink code.
      
      Once the ATM neighbour table is added to the list, there are two
      tables with family == AF_INET there, and ARP entries sent via netlink
      go into the first table with matching family. This is indeterminate
      and often wrong.
      
      To see the bug, on a kernel with CLIP enabled, create a standard IPv4
      ARP entry by pinging an unused address on a local subnet. Then attempt
      to complete that entry by doing
      
      ip neigh replace <ip address> lladdr <some mac address> nud reachable
      
      Looking at the ARP tables by using 
      
      ip neigh show
      
      will reveal two ARP entries for the same address. One of these can be
      found in /proc/net/arp, and the other in /proc/net/atm/arp.
      
      This patch adds a new function, neigh_table_init_no_netlink() which
      does everything the neigh_table_init() does, except add the table to
      the netlink all-arp-tables chain. In addition neigh_table_init() has a
      check that all tables on the chain have a distinct address family.
      The init call in clip.c is changed to call
      neigh_table_init_no_netlink().
      
      Since ATM ARP tables are rather more complicated than can currently be
      handled by the available rtattrs in the netlink protocol, no
      functionality is lost by this patch, and non-ATM ARP manipulation via
      netlink is rescued. A more complete solution would involve a rtattr
      for ATM ARP entries and some way for the netlink code to give
      neigh_add and friends more information than just address family with
      which to find the correct ARP table.
      
      [ I've changed the assertion checking in neigh_table_init() to not
        use BUG_ON() while holding neigh_tbl_lock.  Instead we remember that
        we found an existing tbl with the same family, and after dropping
        the lock we'll give a diagnostic kernel log message and a stack dump.
        -DaveM ]
      Signed-off-by: NSimon Kelley <simon@thekelleys.org.uk>
      Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      bd89efc5
  16. 11 4月, 2006 1 次提交
  17. 10 4月, 2006 1 次提交
  18. 21 3月, 2006 2 次提交
  19. 26 10月, 2005 1 次提交
  20. 23 10月, 2005 3 次提交
    • H
      [NEIGH] Fix timer leak in neigh_changeaddr · 49636bb1
      Herbert Xu 提交于
      neigh_changeaddr attempts to delete neighbour timers without setting
      nud_state.  This doesn't work because the timer may have already fired
      when we acquire the write lock in neigh_changeaddr.  The result is that
      the timer may keep firing for quite a while until the entry reaches
      NEIGH_FAILED.
      
      It should be setting the nud_state straight away so that if the timer
      has already fired it can simply exit once we relinquish the lock.
      
      In fact, this whole function is simply duplicating the logic in
      neigh_ifdown which in turn is already doing the right thing when
      it comes to deleting timers and setting nud_state.
      
      So all we have to do is take that code out and put it into a common
      function and make both neigh_changeaddr and neigh_ifdown call it.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      49636bb1
    • H
      [NEIGH] Fix add_timer race in neigh_add_timer · 6fb9974f
      Herbert Xu 提交于
      neigh_add_timer cannot use add_timer unconditionally.  The reason is that
      by the time it has obtained the write lock someone else (e.g., neigh_update)
      could have already added a new timer.
      
      So it should only use mod_timer and deal with its return value accordingly.
      
      This bug would have led to rare neighbour cache entry leaks.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      6fb9974f
    • H
      [NEIGH] Print stack trace in neigh_add_timer · 20375502
      Herbert Xu 提交于
      Stack traces are very helpful in determining the exact nature of a bug.
      So let's print a stack trace when the timer is added twice.
      Signed-off-by: NHerbert Xu <herbert@gondor.apana.org.au>
      20375502
  21. 28 9月, 2005 1 次提交
  22. 25 9月, 2005 1 次提交
  23. 30 8月, 2005 2 次提交
  24. 29 6月, 2005 1 次提交
  25. 24 6月, 2005 1 次提交