1. 25 7月, 2008 2 次提交
    • F
      add a helper function to test if an object is on the stack · 8b05c7e6
      FUJITA Tomonori 提交于
      lib/debugobjects.c has a function to test if an object is on the stack.
      The block layer and ide needs it (they need to avoid DMA from/to stack
      buffers).  This patch moves the function to include/linux/sched.h so that
      everyone can use it.
      
      lib/debugobjects.c uses current->stack but this patch uses a
      task_stack_page() accessor, which is a preferable way to access the stack.
      Signed-off-by: NFUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      8b05c7e6
    • M
      mm: add a basic debugging framework for memory initialisation · 6b74ab97
      Mel Gorman 提交于
      Boot initialisation is very complex, with significant numbers of
      architecture-specific routines, hooks and code ordering.  While significant
      amounts of the initialisation is architecture-independent, it trusts the data
      received from the architecture layer.  This is a mistake, and has resulted in
      a number of difficult-to-diagnose bugs.
      
      This patchset adds some validation and tracing to memory initialisation.  It
      also introduces a few basic defensive measures.  The validation code can be
      explicitly disabled for embedded systems.
      
      This patch:
      
      Add additional debugging and verification code for memory initialisation.
      
      Once enabled, the verification checks are always run and when required
      additional debugging information may be outputted via a mminit_loglevel=
      command-line parameter.
      
      The verification code is placed in a new file mm/mm_init.c.  Ideally other mm
      initialisation code will be moved here over time.
      Signed-off-by: NMel Gorman <mel@csn.ul.ie>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Andy Whitcroft <apw@shadowen.org>
      Cc: Ingo Molnar <mingo@elte.hu>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      6b74ab97
  2. 24 7月, 2008 1 次提交
  3. 23 7月, 2008 1 次提交
    • T
      sg: reimplement sg mapping iterator · 137d3edb
      Tejun Heo 提交于
      This is alternative implementation of sg content iterator introduced
      by commit 83e7d317... from Pierre Ossman in next-20080716.  As there's
      already an sg iterator which iterates over sg entries themselves, name
      this sg_mapping_iterator.
      
      Slightly edited description from the original implementation follows.
      
      Iteration over a sg list is not that trivial when you take into
      account that memory pages might have to be mapped before being used.
      Unfortunately, that means that some parts of the kernel restrict
      themselves to directly accesible memory just to not have to deal with
      the mess.
      
      This patch adds a simple iterator system that allows any code to
      easily traverse an sg list and not have to deal with all the details.
      The user can decide to consume part of the iteration.  Also, iteration
      can be stopped and resumed later if releasing the kmap between
      iteration steps is necessary.  These features are useful to implement
      piecemeal sg copying for interrupt drive PIO for example.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NPierre Ossman <drzeus@drzeus.cx>
      137d3edb
  4. 22 7月, 2008 4 次提交
  5. 19 7月, 2008 2 次提交
  6. 17 7月, 2008 2 次提交
    • I
      ftrace: do not trace library functions · 2464a609
      Ingo Molnar 提交于
      make function tracing more robust: do not trace library functions.
      
      We've already got a sizable list of exceptions:
      
       ifdef CONFIG_FTRACE
       # Do not profile string.o, since it may be used in early boot or vdso
       CFLAGS_REMOVE_string.o = -pg
       # Also do not profile any debug utilities
       CFLAGS_REMOVE_spinlock_debug.o = -pg
       CFLAGS_REMOVE_list_debug.o = -pg
       CFLAGS_REMOVE_debugobjects.o = -pg
       CFLAGS_REMOVE_find_next_bit.o = -pg
       CFLAGS_REMOVE_cpumask.o = -pg
       CFLAGS_REMOVE_bitmap.o = -pg
       endif
      
      ... and the pattern has been that random library functionality showed
      up in ftrace's critical path (outside of its recursion check), causing
      hard to debug lockups.
      
      So be a bit defensive about it and exclude all lib/*.o functions by
      default. It's not that they are overly interesting for tracing purposes
      anyway. Specific ones can still be traced, in an opt-in manner.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2464a609
    • I
      ftrace: fix lockup with MAXSMP · 9fa11137
      Ingo Molnar 提交于
      MAXSMP brings in lots of use of various bitops in smp_processor_id()
      and friends - causing ftrace to lock up during bootup:
      
        calling  anon_inode_init+0x0/0x130
        initcall anon_inode_init+0x0/0x130 returned 0 after 0 msecs
        calling  acpi_event_init+0x0/0x57
        [ hard hang ]
      
      So exclude the bitops facilities from tracing.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9fa11137
  7. 12 7月, 2008 2 次提交
  8. 08 7月, 2008 4 次提交
  9. 07 7月, 2008 4 次提交
    • L
      vsprintf: add support for '%pS' and '%pF' pointer formats · 0fe1ef24
      Linus Torvalds 提交于
      They print out a pointer in symbolic format, if possible (ie using
      symbolic KALLSYMS information).  The '%pS' format is for regular direct
      pointers (which can point to data or code and that you find on the stack
      during backtraces etc), while '%pF' is for C function pointer types.
      
      On most architectures, the two mean exactly the same thing, but some
      architectures use an indirect pointer for C function pointers, where the
      function pointer points to a function descriptor (which in turn contains
      the actual pointer to the code).  The '%pF' code automatically does the
      appropriate function descriptor dereference on such architectures.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0fe1ef24
    • L
      vsprintf: add infrastructure support for extended '%p' specifiers · 4d8a743c
      Linus Torvalds 提交于
      This expands the kernel '%p' handling with an arbitrary alphanumberic
      specifier extension string immediately following the '%p'.  Right now
      it's just being ignored, but the next commit will start adding some
      specific pointer type extensions.
      
      NOTE! The reason the extension is appended to the '%p' is to allow
      minimal gcc type checking: gcc will still see the '%p' and will check
      that the argument passed in is indeed a pointer, and yet will not
      complain about the extended information that gcc doesn't understand
      about (on the other hand, it also won't actually check that the pointer
      type and the extension are compatible).
      
      Alphanumeric characters were chosen because there is no sane existing
      use for a string format with a hex pointer representation immediately
      followed by alphanumerics (which is what such a format string would have
      traditionally resulted in).
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      4d8a743c
    • L
      vsprintf: split out '%p' handling logic · 78a8bf69
      Linus Torvalds 提交于
      The actual code is the same, just split out into a helper function.
      This makes it easier to read, and allows for simple future extension
      of %p handling.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      78a8bf69
    • L
      vsprintf: split out '%s' handling logic · 0f9bfa56
      Linus Torvalds 提交于
      The actual code is the same, just split out into a helper function.
      This makes it easier to read, and allows for future sharing of the
      string code.
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      0f9bfa56
  10. 05 7月, 2008 2 次提交
  11. 01 7月, 2008 1 次提交
  12. 28 6月, 2008 1 次提交
  13. 19 6月, 2008 1 次提交
    • P
      rcu: make rcutorture more vicious: reinstate boot-time testing · 31a72bce
      Paul E. McKenney 提交于
      This patch re-institutes the ability to build rcutorture directly into
      the Linux kernel.  The reason that this capability was removed was that
      this could result in your kernel being pretty much useless, as rcutorture
      would be running starting from early boot.  This problem has been avoided
      by (1) making rcutorture run only three seconds of every six by default,
      (2) adding a CONFIG_RCU_TORTURE_TEST_RUNNABLE that permits rcutorture
      to be quiesced at boot time, and (3) adding a sysctl in /proc named
      /proc/sys/kernel/rcutorture_runnable that permits rcutorture to be
      quiesced and unquiesced when built into the kernel.
      
      Please note that this /proc file is -not- available when rcutorture
      is built as a module.  Please also note that to get the earlier
      take-no-prisoners behavior, you must use the boot command line to set
      rcutorture's "stutter" parameter to zero.
      
      The rcutorture quiescing mechanism is currently quite crude: loops
      in each rcutorture process that poll a global variable once per tick.
      Suggestions for improvement are welcome.  The default action will
      be to reduce the polling rate to a few times per second.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Suggested-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      31a72bce
  14. 18 6月, 2008 1 次提交
    • V
      debugobjects: fix lockdep warning · 50db04dd
      Vegard Nossum 提交于
      Daniel J Blueman reported:
      | =======================================================
      | [ INFO: possible circular locking dependency detected ]
      | 2.6.26-rc5-201c #1
      | -------------------------------------------------------
      | nscd/3669 is trying to acquire lock:
      |  (&n->list_lock){.+..}, at: [<ffffffff802bab03>] deactivate_slab+0x173/0x1e0
      |
      | but task is already holding lock:
      |  (&obj_hash[i].lock){++..}, at: [<ffffffff803fa56f>]
      | __debug_object_init+0x2f/0x350
      |
      | which lock already depends on the new lock.
      
      There are two locks involved here; the first is a SLUB-local lock, and
      the second is a debugobjects-local lock. They are basically taken in two
      different orders:
      
      1. SLUB { debugobjects { ... } }
      2. debugobjects { SLUB { ... } }
      
      This patch changes pattern #2 by trying to fill the memory pool (e.g.
      the call into SLUB/kmalloc()) outside the debugobjects lock, so now the
      two patterns look like this:
      
      1. SLUB { debugobjects { ... } }
      2. SLUB { } debugobjects { ... }
      
      [ daniel.blueman@gmail.com: pool_lock needs to be taken irq safe in fill_pool ]
      Reported-by: NDaniel J Blueman <daniel.blueman@gmail.com>
      Signed-off-by: NVegard Nossum <vegard.nossum@gmail.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      50db04dd
  15. 16 6月, 2008 1 次提交
    • I
      Revert "prohibit rcutorture from being compiled into the kernel" · 1462a200
      Ingo Molnar 提交于
      This reverts commit 9aaffc89.
      
      That commit was a very bad idea. RCU_TORTURE found many boot timing
      bugs and other sorts of bugs in the past, so excluding it from
      boot images is very silly.
      
      The option already depends on DEBUG_KERNEL and is disabled by default.
      Even when it runs, the test threads are reniced. If it annoys people
      we could add a runtime sysctl.
      1462a200
  16. 13 6月, 2008 1 次提交
    • N
      radix-tree: fix small lockless radix-tree bug · 643b52b9
      Nick Piggin 提交于
      We shrink a radix tree when its root node has only one child, in the left
      most slot.  The child becomes the new root node.  To perform this
      operation in a manner compatible with concurrent lockless lookups, we
      atomically switch the root pointer from the parent to its child.
      
      However a concurrent lockless lookup may now have loaded a pointer to the
      parent (and is presently deciding what to do next).  For this reason, we
      also have to keep the parent node in a valid state after shrinking the
      tree, until the next RCU grace period -- otherwise this lookup with the
      parent pointer may not do the right thing.  Notably, we need to keep the
      child in the left most slot there in case that is requested by the lookup.
      
      This is all pretty standard RCU stuff.  It is worth repeating because in
      my eagerness to obey the radix tree node constructor scheme, I had broken
      it by zeroing the radix tree node before the grace period.
      
      What could happen is that a lookup can load the parent pointer, then
      decide it wants to follow the left most child slot, only to find the slot
      contained NULL due to the concurrent shrinker having zeroed the parent
      node before waiting for a grace period.  The lookup would return a false
      negative as a result.
      
      Fix it by doing that clearing in the RCU callback.  I would normally want
      to rip out the constructor entirely, but radix tree nodes are one of those
      places where they make sense (only few cachelines will be touched soon
      after allocation).
      
      This was never actually found in any lockless pagecache testing or by the
      test harness, but by seeing the odd problem with my scalable vmap rewrite.
       I have not tickled the test harness into reproducing it yet, but I'll
      keep working at it.
      
      Fortunately, it is not a problem anywhere lockless pagecache is used in
      mainline kernels (pagecache probe is not a guarantee, and brd does not
      have concurrent lookups and deletes).
      Signed-off-by: NNick Piggin <npiggin@suse.de>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: "Paul E. McKenney" <paulmck@us.ibm.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      643b52b9
  17. 12 6月, 2008 2 次提交
    • J
      add an inlined version of iter_div_u64_rem · d5e181f7
      Jeremy Fitzhardinge 提交于
      iter_div_u64_rem is used in the x86-64 vdso, which cannot call other
      kernel code.  For this case, provide the always_inlined version,
      __iter_div_u64_rem.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      d5e181f7
    • J
      common implementation of iterative div/mod · f595ec96
      Jeremy Fitzhardinge 提交于
      We have a few instances of the open-coded iterative div/mod loop, used
      when we don't expcet the dividend to be much bigger than the divisor.
      Unfortunately modern gcc's have the tendency to strength "reduce" this
      into a full mod operation, which isn't necessarily any faster, and
      even if it were, doesn't exist if gcc implements it in libgcc.
      
      The workaround is to put a dummy asm statement in the loop to prevent
      gcc from performing the transformation.
      
      This patch creates a single implementation of this loop, and uses it
      to replace the open-coded versions I know about.
      Signed-off-by: NJeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: john stultz <johnstul@us.ibm.com>
      Cc: Segher Boessenkool <segher@kernel.crashing.org>
      Cc: Christian Kujau <lists@nerdbynature.de>
      Cc: Robert Hancock <hancockr@shaw.ca>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      f595ec96
  18. 11 6月, 2008 1 次提交
  19. 07 6月, 2008 1 次提交
  20. 25 5月, 2008 2 次提交
  21. 24 5月, 2008 4 次提交