1. 29 12月, 2008 1 次提交
  2. 17 10月, 2008 2 次提交
    • T
      block: add BIG FAT WARNING to CONFIG_DEBUG_BLOCK_EXT_DEVT · 0e11e342
      Tejun Heo 提交于
      CONFIG_DEBUG_BLOCK_EXT_DEVT can break booting even on some modern
      distros.  Add BIG FAT WARNING to keep people at a safe distance.
      Signed-off-by: NTejun Heo <tj@kernel.org>
      Signed-off-by: NJens Axboe <jens.axboe@oracle.com>
      0e11e342
    • J
      driver core: basic infrastructure for per-module dynamic debug messages · 346e15be
      Jason Baron 提交于
      Base infrastructure to enable per-module debug messages.
      
      I've introduced CONFIG_DYNAMIC_PRINTK_DEBUG, which when enabled centralizes
      control of debugging statements on a per-module basis in one /proc file,
      currently, <debugfs>/dynamic_printk/modules. When, CONFIG_DYNAMIC_PRINTK_DEBUG,
      is not set, debugging statements can still be enabled as before, often by
      defining 'DEBUG' for the proper compilation unit. Thus, this patch set has no
      affect when CONFIG_DYNAMIC_PRINTK_DEBUG is not set.
      
      The infrastructure currently ties into all pr_debug() and dev_dbg() calls. That
      is, if CONFIG_DYNAMIC_PRINTK_DEBUG is set, all pr_debug() and dev_dbg() calls
      can be dynamically enabled/disabled on a per-module basis.
      
      Future plans include extending this functionality to subsystems, that define 
      their own debug levels and flags.
      
      Usage:
      
      Dynamic debugging is controlled by the debugfs file, 
      <debugfs>/dynamic_printk/modules. This file contains a list of the modules that
      can be enabled. The format of the file is as follows:
      
      	<module_name> <enabled=0/1>
      		.
      		.
      		.
      
      	<module_name> : Name of the module in which the debug call resides
      	<enabled=0/1> : whether the messages are enabled or not
      
      For example:
      
      	snd_hda_intel enabled=0
      	fixup enabled=1
      	driver enabled=0
      
      Enable a module:
      
      	$echo "set enabled=1 <module_name>" > dynamic_printk/modules
      
      Disable a module:
      
      	$echo "set enabled=0 <module_name>" > dynamic_printk/modules
      
      Enable all modules:
      
      	$echo "set enabled=1 all" > dynamic_printk/modules
      
      Disable all modules:
      
      	$echo "set enabled=0 all" > dynamic_printk/modules
      
      Finally, passing "dynamic_printk" at the command line enables
      debugging for all modules. This mode can be turned off via the above
      disable command.
      
      [gkh: minor cleanups and tweaks to make the build work quietly]
      Signed-off-by: NJason Baron <jbaron@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      
      346e15be
  3. 09 10月, 2008 4 次提交
  4. 03 10月, 2008 1 次提交
    • P
      rcu: RCU-based detection of stalled CPUs for Classic RCU · 2133b5d7
      Paul E. McKenney 提交于
      This patch adds stalled-CPU detection to Classic RCU.  This capability
      is enabled by a new config variable CONFIG_RCU_CPU_STALL_DETECTOR, which
      defaults disabled.
      
      This is a debugging feature to detect infinite loops in kernel code, not
      something that non-kernel-hackers would be expected to care about.
      
      This feature can detect looping CPUs in !PREEMPT builds and looping CPUs
      with preemption disabled in PREEMPT builds.  This is essentially a port of
      this functionality from the treercu patch, replacing the stall debug patch
      that is already in tip/core/rcu (commit 67182ae1).
      
      The changes from the patch in tip/core/rcu include making the config
      variable name match that in treercu, changing from seconds to jiffies to
      avoid spurious warnings, and printing a boot message when this feature
      is enabled.
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      2133b5d7
  5. 03 9月, 2008 1 次提交
    • T
      powerpc: Work around gcc's -fno-omit-frame-pointer bug · 7563dc64
      Tony Breeds 提交于
      This bug is causing random crashes
      (http://bugzilla.kernel.org/show_bug.cgi?id=11414).
      
      -fno-omit-frame-pointer is only needed on powerpc when -pg is also
      supplied, and there is a gcc bug that causes incorrect code generation
      on 32-bit powerpc when -fno-omit-frame-pointer is used---it uses stack
      locations below the stack pointer, which is not allowed by the ABI
      because those locations can and sometimes do get corrupted by an
      interrupt.
      
      This ensures that CONFIG_FRAME_POINTER is only selected by ftrace.
      When CONFIG_FTRACE is enabled we also pass -mno-sched-epilog to work
      around the gcc codegen bug.
      
      Patch based on work by:
      	Andreas Schwab <schwab@suse.de>
      	Segher Boessenkool <segher@kernel.crashing.org>
      Signed-off-by: NTony Breeds <tony@bakeyournoodle.com>
      Signed-off-by: NPaul Mackerras <paulus@samba.org>
      7563dc64
  6. 17 8月, 2008 1 次提交
  7. 13 8月, 2008 1 次提交
    • R
      docsrc: build Documentation/ sources · 3794f3e8
      Randy Dunlap 提交于
      Currently source files in the Documentation/ sub-dir can easily bit-rot
      since they are not generally buildable, either because they are hidden in
      text files or because there are no Makefile rules for them.  This needs to
      be fixed so that the source files remain usable and good examples of code
      instead of bad examples.
      
      Add the ability to build source files that are in the Documentation/ dir.
      Add to Kconfig as "BUILD_DOCSRC" config symbol.
      
      Use "CONFIG_BUILD_DOCSRC=1 make ..." to build objects from the
      Documentation/ sources.  Or enable BUILD_DOCSRC in the *config system.
      However, this symbol depends on HEADERS_CHECK since the header files need
      to be installed (for userspace builds).
      
      Built (using cross-tools) for x86-64, i386, alpha, ia64, sparc32,
      sparc64, powerpc, sh, m68k, & mips.
      Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
      Reviewed-by: NSam Ravnborg <sam@ravnborg.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3794f3e8
  8. 11 8月, 2008 1 次提交
    • P
      rcu, debug: detect stalled grace periods · 67182ae1
      Paul E. McKenney 提交于
      this is a diagnostic patch for Classic RCU.
      
      The approach is to record a timestamp at the beginning
      of the grace period (in rcu_start_batch()), then have
      rcu_check_callbacks() complain if:
      
       1.	it is running on a CPU that has holding up grace periods for
       	a long time (say one second).  This will identify the culprit
       	assuming that the culprit has not disabled hardware irqs,
       	instruction execution, or some such.
      
       2.	it is running on a CPU that is not holding up grace periods,
       	but grace periods have been held up for an even longer time
       	(say two seconds).
      
      It is enabled via the default-off CONFIG_DEBUG_RCU_STALL kernel parameter.
      
      Rather than exponential backoff, it backs off to once per 30 seconds.
      My feeling upon thinking on it was that if you have stalled RCU grace
      periods for that long, a few extra printk() messages are probably the
      least of your worries...
      Signed-off-by: NPaul E. McKenney <paulmck@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Yinghai Lu <yhlu.kernel@gmail.com>
      Cc: David Witbrodt <dawitbro@sbcglobal.net>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      67182ae1
  9. 25 7月, 2008 1 次提交
    • 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
  10. 22 7月, 2008 1 次提交
  11. 28 6月, 2008 1 次提交
  12. 19 6月, 2008 2 次提交
    • J
      MM: virtual address debug · 59ea7463
      Jiri Slaby 提交于
      Add some (configurable) expensive sanity checking to catch wrong address
      translations on x86.
      
      - create linux/mmdebug.h file to be able include this file in
        asm headers to not get unsolvable loops in header files
      - __phys_addr on x86_32 became a function in ioremap.c since
        PAGE_OFFSET, is_vmalloc_addr and VMALLOC_* non-constasts are undefined
        if declared in page_32.h
      - add __phys_addr_const for initializing doublefault_tss.__cr3
      
      Tested on 386, 386pae, x86_64 and x86_64 numa=fake=2.
      
      Contains Andi's enable numa virtual address debug patch.
      Signed-off-by: NJiri Slaby <jirislaby@gmail.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      59ea7463
    • 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
  13. 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
  14. 25 5月, 2008 2 次提交
  15. 24 5月, 2008 1 次提交
  16. 30 4月, 2008 2 次提交
    • T
      debugobjects: add timer specific object debugging code · c6f3a97f
      Thomas Gleixner 提交于
      Add calls to the generic object debugging infrastructure and provide fixup
      functions which allow to keep the system alive when recoverable problems have
      been detected by the object debugging core code.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Acked-by: NIngo Molnar <mingo@elte.hu>
      Cc: Greg KH <greg@kroah.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c6f3a97f
    • T
      infrastructure to debug (dynamic) objects · 3ac7fe5a
      Thomas Gleixner 提交于
      We can see an ever repeating problem pattern with objects of any kind in the
      kernel:
      
      1) freeing of active objects
      2) reinitialization of active objects
      
      Both problems can be hard to debug because the crash happens at a point where
      we have no chance to decode the root cause anymore.  One problem spot are
      kernel timers, where the detection of the problem often happens in interrupt
      context and usually causes the machine to panic.
      
      While working on a timer related bug report I had to hack specialized code
      into the timer subsystem to get a reasonable hint for the root cause.  This
      debug hack was fine for temporary use, but far from a mergeable solution due
      to the intrusiveness into the timer code.
      
      The code further lacked the ability to detect and report the root cause
      instantly and keep the system operational.
      
      Keeping the system operational is important to get hold of the debug
      information without special debugging aids like serial consoles and special
      knowledge of the bug reporter.
      
      The problems described above are not restricted to timers, but timers tend to
      expose it usually in a full system crash.  Other objects are less explosive,
      but the symptoms caused by such mistakes can be even harder to debug.
      
      Instead of creating specialized debugging code for the timer subsystem a
      generic infrastructure is created which allows developers to verify their code
      and provides an easy to enable debug facility for users in case of trouble.
      
      The debugobjects core code keeps track of operations on static and dynamic
      objects by inserting them into a hashed list and sanity checking them on
      object operations and provides additional checks whenever kernel memory is
      freed.
      
      The tracked object operations are:
      - initializing an object
      - adding an object to a subsystem list
      - deleting an object from a subsystem list
      
      Each operation is sanity checked before the operation is executed and the
      subsystem specific code can provide a fixup function which allows to prevent
      the damage of the operation.  When the sanity check triggers a warning message
      and a stack trace is printed.
      
      The list of operations can be extended if the need arises.  For now it's
      limited to the requirements of the first user (timers).
      
      The core code enqueues the objects into hash buckets.  The hash index is
      generated from the address of the object to simplify the lookup for the check
      on kfree/vfree.  Each bucket has it's own spinlock to avoid contention on a
      global lock.
      
      The debug code can be compiled in without being active.  The runtime overhead
      is minimal and could be optimized by asm alternatives.  A kernel command line
      option enables the debugging code.
      
      Thanks to Ingo Molnar for review, suggestions and cleanup patches.
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Cc: Greg KH <greg@kroah.com>
      Cc: Randy Dunlap <randy.dunlap@oracle.com>
      Cc: Kay Sievers <kay.sievers@vrfy.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      3ac7fe5a
  17. 26 4月, 2008 1 次提交
    • A
      Add option to enable -Wframe-larger-than= on gcc 4.4 · 35bb5b1e
      Andi Kleen 提交于
      Add option to enable -Wframe-larger-than= on gcc 4.4
      
      gcc mainline (upcoming 4.4) added a new -Wframe-larger-than=...
      option to warn at build time about too large stack frames. Add a config
      option to enable this warning, since this very useful for the kernel.
      
      I choose (somewhat arbitarily) 2048 as default warning threshold for 64bit
      and 1024 as default for 32bit architectures.  With some research and
      fixing all the code for smaller values these defaults should be probably
      lowered.
      
      With the default allyesconfigs have some new warnings, but I think
      that is all code that should be just fixed.
      
      At some point (when gcc 4.4 is released and widely used) this should
      obsolete make checkstack
      Signed-off-by: NAndi Kleen <ak@suse.de>
      Signed-off-by: NSam Ravnborg <sam@ravnborg.org>
      35bb5b1e
  18. 19 4月, 2008 1 次提交
  19. 18 4月, 2008 2 次提交
  20. 17 4月, 2008 1 次提交
  21. 14 4月, 2008 1 次提交
    • C
      slub: Deal with config variable dependencies · 5b06c853
      Christoph Lameter 提交于
      count_partial() is used by both slabinfo and the sysfs proc support. Move
      the function directly before the beginning of the sysfs code so that it can
      be easily found. Rework the preprocessor conditional to take into account
      that slub sysfs support depends on CONFIG_SYSFS *and* CONFIG_SLUB_DEBUG.
      
      Make CONFIG_SLUB_STATS depend on CONFIG_SLUB_DEBUG and CONFIG_SYSFS. There
      is no point of keeping statistics if no one can restrive them.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      Signed-off-by: NPekka Enberg <penberg@cs.helsinki.fi>
      5b06c853
  22. 24 2月, 2008 1 次提交
  23. 15 2月, 2008 1 次提交
  24. 10 2月, 2008 1 次提交
  25. 09 2月, 2008 1 次提交
  26. 08 2月, 2008 1 次提交
    • C
      SLUB: Support for performance statistics · 8ff12cfc
      Christoph Lameter 提交于
      The statistics provided here allow the monitoring of allocator behavior but
      at the cost of some (minimal) loss of performance. Counters are placed in
      SLUB's per cpu data structure. The per cpu structure may be extended by the
      statistics to grow larger than one cacheline which will increase the cache
      footprint of SLUB.
      
      There is a compile option to enable/disable the inclusion of the runtime
      statistics and its off by default.
      
      The slabinfo tool is enhanced to support these statistics via two options:
      
      -D 	Switches the line of information displayed for a slab from size
      	mode to activity mode.
      
      -A	Sorts the slabs displayed by activity. This allows the display of
      	the slabs most important to the performance of a certain load.
      
      -r	Report option will report detailed statistics on
      
      Example (tbench load):
      
      slabinfo -AD		->Shows the most active slabs
      
      Name                   Objects    Alloc     Free   %Fast
      skbuff_fclone_cache         33 111953835 111953835  99  99
      :0000192                  2666  5283688  5281047  99  99
      :0001024                   849  5247230  5246389  83  83
      vm_area_struct            1349   119642   118355  91  22
      :0004096                    15    66753    66751  98  98
      :0000064                  2067    25297    23383  98  78
      dentry                   10259    28635    18464  91  45
      :0000080                 11004    18950     8089  98  98
      :0000096                  1703    12358    10784  99  98
      :0000128                   762    10582     9875  94  18
      :0000512                   184     9807     9647  95  81
      :0002048                   479     9669     9195  83  65
      anon_vma                   777     9461     9002  99  71
      kmalloc-8                 6492     9981     5624  99  97
      :0000768                   258     7174     6931  58  15
      
      So the skbuff_fclone_cache is of highest importance for the tbench load.
      Pretty high load on the 192 sized slab. Look for the aliases
      
      slabinfo -a | grep 000192
      :0000192     <- xfs_btree_cur filp kmalloc-192 uid_cache tw_sock_TCP
      	request_sock_TCPv6 tw_sock_TCPv6 skbuff_head_cache xfs_ili
      
      Likely skbuff_head_cache.
      
      
      Looking into the statistics of the skbuff_fclone_cache is possible through
      
      slabinfo skbuff_fclone_cache	->-r option implied if cache name is mentioned
      
      
      .... Usual output ...
      
      Slab Perf Counter       Alloc     Free %Al %Fr
      --------------------------------------------------
      Fastpath             111953360 111946981  99  99
      Slowpath                 1044     7423   0   0
      Page Alloc                272      264   0   0
      Add partial                25      325   0   0
      Remove partial             86      264   0   0
      RemoteObj/SlabFrozen      350     4832   0   0
      Total                111954404 111954404
      
      Flushes       49 Refill        0
      Deactivate Full=325(92%) Empty=0(0%) ToHead=24(6%) ToTail=1(0%)
      
      Looks good because the fastpath is overwhelmingly taken.
      
      
      skbuff_head_cache:
      
      Slab Perf Counter       Alloc     Free %Al %Fr
      --------------------------------------------------
      Fastpath              5297262  5259882  99  99
      Slowpath                 4477    39586   0   0
      Page Alloc                937      824   0   0
      Add partial                 0     2515   0   0
      Remove partial           1691      824   0   0
      RemoteObj/SlabFrozen     2621     9684   0   0
      Total                 5301739  5299468
      
      Deactivate Full=2620(100%) Empty=0(0%) ToHead=0(0%) ToTail=0(0%)
      
      
      Descriptions of the output:
      
      Total:		The total number of allocation and frees that occurred for a
      		slab
      
      Fastpath:	The number of allocations/frees that used the fastpath.
      
      Slowpath:	Other allocations
      
      Page Alloc:	Number of calls to the page allocator as a result of slowpath
      		processing
      
      Add Partial:	Number of slabs added to the partial list through free or
      		alloc (occurs during cpuslab flushes)
      
      Remove Partial:	Number of slabs removed from the partial list as a result of
      		allocations retrieving a partial slab or by a free freeing
      		the last object of a slab.
      
      RemoteObj/Froz:	How many times were remotely freed object encountered when a
      		slab was about to be deactivated. Frozen: How many times was
      		free able to skip list processing because the slab was in use
      		as the cpuslab of another processor.
      
      Flushes:	Number of times the cpuslab was flushed on request
      		(kmem_cache_shrink, may result from races in __slab_alloc)
      
      Refill:		Number of times we were able to refill the cpuslab from
      		remotely freed objects for the same slab.
      
      Deactivate:	Statistics how slabs were deactivated. Shows how they were
      		put onto the partial list.
      
      In general fastpath is very good. Slowpath without partial list processing is
      also desirable. Any touching of partial list uses node specific locks which
      may potentially cause list lock contention.
      Signed-off-by: NChristoph Lameter <clameter@sgi.com>
      8ff12cfc
  27. 03 2月, 2008 2 次提交
  28. 02 2月, 2008 1 次提交
  29. 30 1月, 2008 3 次提交
    • B
      x86: early boot debugging via FireWire (ohci1394_dma=early) · f212ec4b
      Bernhard Kaindl 提交于
      This patch adds a new configuration option, which adds support for a new
      early_param which gets checked in arch/x86/kernel/setup_{32,64}.c:setup_arch()
      to decide wether OHCI-1394 FireWire controllers should be initialized and
      enabled for physical DMA access to allow remote debugging of early problems
      like issues ACPI or other subsystems which are executed very early.
      
      If the config option is not enabled, no code is changed, and if the boot
      paramenter is not given, no new code is executed, and independent of that,
      all new code is freed after boot, so the config option can be even enabled
      in standard, non-debug kernels.
      
      With specialized tools, it is then possible to get debugging information
      from machines which have no serial ports (notebooks) such as the printk
      buffer contents, or any data which can be referenced from global pointers,
      if it is stored below the 4GB limit and even memory dumps of of the physical
      RAM region below the 4GB limit can be taken without any cooperation from the
      CPU of the host, so the machine can be crashed early, it does not matter.
      
      In the extreme, even kernel debuggers can be accessed in this way. I wrote
      a small kgdb module and an accompanying gdb stub for FireWire which allows
      to gdb to talk to kgdb using remote remory reads and writes over FireWire.
      
      An version of the gdb stub fore FireWire is able to read all global data
      from a system which is running a a normal kernel without any kernel debugger,
      without any interruption or support of the system's CPU. That way, e.g. the
      task struct and so on can be read and even manipulated when the physical DMA
      access is granted.
      
      A HOWTO is included in this patch, in Documentation/debugging-via-ohci1394.txt
      and I've put a copy online at
      ftp://ftp.suse.de/private/bk/firewire/docs/debugging-via-ohci1394.txt
      
      It also has links to all the tools which are available to make use of it
      another copy of it is online at:
      ftp://ftp.suse.de/private/bk/firewire/kernel/ohci1394_dma_early-v2.diffSigned-Off-By: NBernhard Kaindl <bk@suse.de>
      Tested-By: NThomas Renninger <trenn@suse.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      f212ec4b
    • A
      x86: add a simple backtrace test module · 6dab2778
      Arjan van de Ven 提交于
      During the work on the x86 32 and 64 bit backtrace code I found it useful
      to have a simple test module to test a process and irq context backtrace.
      Since the existing backtrace code was buggy, I figure it might be useful
      to have such a test module in the kernel so that maybe we can even
      detect such bugs earlier..
      
      [ mingo@elte.hu: build fix ]
      Signed-off-by: NArjan van de Ven <arjan@linux.intel.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      6dab2778
    • A
      x86: kprobes: add kprobes smoke tests that run on boot · 8c1c9356
      Ananth N Mavinakayanahalli 提交于
      Here is a quick and naive smoke test for kprobes. This is intended to
      just verify if some unrelated change broke the *probes subsystem. It is
      self contained, architecture agnostic and isn't of any great use by itself.
      
      This needs to be built in the kernel and runs a basic set of tests to
      verify if kprobes, jprobes and kretprobes run fine on the kernel. In case
      of an error, it'll print out a message with a "BUG" prefix.
      
      This is a start; we intend to add more tests to this bucket over time.
      
      Thanks to Jim Keniston and Masami Hiramatsu for comments and suggestions.
      
      Tested on x86 (32/64) and powerpc.
      Signed-off-by: NAnanth N Mavinakayanahalli <ananth@in.ibm.com>
      Acked-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: NThomas Gleixner <tglx@linutronix.de>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8c1c9356