1. 15 7月, 2017 3 次提交
  2. 13 7月, 2017 1 次提交
    • D
      fault-inject: support systematic fault injection · e41d5818
      Dmitry Vyukov 提交于
      Add /proc/self/task/<current-tid>/fail-nth file that allows failing
      0-th, 1-st, 2-nd and so on calls systematically.
      Excerpt from the added documentation:
      
       "Write to this file of integer N makes N-th call in the current task
        fail (N is 0-based). Read from this file returns a single char 'Y' or
        'N' that says if the fault setup with a previous write to this file
        was injected or not, and disables the fault if it wasn't yet injected.
        Note that this file enables all types of faults (slab, futex, etc).
        This setting takes precedence over all other generic settings like
        probability, interval, times, etc. But per-capability settings (e.g.
        fail_futex/ignore-private) take precedence over it. This feature is
        intended for systematic testing of faults in a single system call. See
        an example below"
      
      Why add a new setting:
      1. Existing settings are global rather than per-task.
         So parallel testing is not possible.
      2. attr->interval is close but it depends on attr->count
         which is non reset to 0, so interval does not work as expected.
      3. Trying to model this with existing settings requires manipulations
         of all of probability, interval, times, space, task-filter and
         unexposed count and per-task make-it-fail files.
      4. Existing settings are per-failure-type, and the set of failure
         types is potentially expanding.
      5. make-it-fail can't be changed by unprivileged user and aggressive
         stress testing better be done from an unprivileged user.
         Similarly, this would require opening the debugfs files to the
         unprivileged user, as he would need to reopen at least times file
         (not possible to pre-open before dropping privs).
      
      The proposed interface solves all of the above (see the example).
      
      We want to integrate this into syzkaller fuzzer.  A prototype has found
      10 bugs in kernel in first day of usage:
      
        https://groups.google.com/forum/#!searchin/syzkaller/%22FAULT_INJECTION%22%7Csort:relevance
      
      I've made the current interface work with all types of our sandboxes.
      For setuid the secret sauce was prctl(PR_SET_DUMPABLE, 1, 0, 0, 0) to
      make /proc entries non-root owned.  So I am fine with the current
      version of the code.
      
      [akpm@linux-foundation.org: fix build]
      Link: http://lkml.kernel.org/r/20170328130128.101773-1-dvyukov@google.comSigned-off-by: NDmitry Vyukov <dvyukov@google.com>
      Cc: Akinobu Mita <akinobu.mita@gmail.com>
      Cc: Michal Hocko <mhocko@kernel.org>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      e41d5818
  3. 20 7月, 2015 1 次提交
    • D
      futex: Fault/error injection capabilities · ab51fbab
      Davidlohr Bueso 提交于
      Although futexes are well known for being a royal pita,
      we really have very little debugging capabilities - except
      for relying on tglx's eye half the time.
      
      By simply making use of the existing fault-injection machinery,
      we can improve this situation, allowing generating artificial
      uaddress faults and deadlock scenarios. Of course, when this is
      disabled in production systems, the overhead for failure checks
      is practically zero -- so this is very cheap at the same time.
      Future work would be nice to now enhance trinity to make use of
      this.
      
      There is a special tunable 'ignore-private', which can filter
      out private futexes. Given the tsk->make_it_fail filter and
      this option, pi futexes can be narrowed down pretty closely.
      Signed-off-by: NDavidlohr Bueso <dbueso@suse.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Darren Hart <darren@dvhart.com>
      Cc: Davidlohr Bueso <dave@stgolabs.net>
      Link: http://lkml.kernel.org/r/1435645562-975-3-git-send-email-dave@stgolabs.netSigned-off-by: NThomas Gleixner <tglx@linutronix.de>
      ab51fbab
  4. 31 7月, 2012 1 次提交
    • A
      fault-injection: add tool to run command with failslab or fail_page_alloc · c24aa64d
      Akinobu Mita 提交于
      This adds tools/testing/fault-injection/failcmd.sh to run a command while
      injecting slab/page allocation failures via fault injection.
      
      Example:
      
      Run a command "make -C tools/testing/selftests/ run_tests" with
      injecting slab allocation failure.
      
      	# ./tools/testing/fault-injection/failcmd.sh \
      		-- make -C tools/testing/selftests/ run_tests
      
      Same as above except to specify 100 times failures at most instead of
      one time at most by default.
      
      	# ./tools/testing/fault-injection/failcmd.sh --times=100 \
      		-- make -C tools/testing/selftests/ run_tests
      
      Same as above except to inject page allocation failure instead of slab
      allocation failure.
      
      	# env FAILCMD_TYPE=fail_page_alloc \
      		./tools/testing/fault-injection/failcmd.sh --times=100 \
      		-- make -C tools/testing/selftests/ run_tests
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      c24aa64d
  5. 27 10月, 2011 2 次提交
  6. 04 8月, 2011 1 次提交
    • A
      fault-injection: add ability to export fault_attr in arbitrary directory · dd48c085
      Akinobu Mita 提交于
      init_fault_attr_dentries() is used to export fault_attr via debugfs.
      But it can only export it in debugfs root directory.
      
      Per Forlin is working on mmc_fail_request which adds support to inject
      data errors after a completed host transfer in MMC subsystem.
      
      The fault_attr for mmc_fail_request should be defined per mmc host and
      export it in debugfs directory per mmc host like
      /sys/kernel/debug/mmc0/mmc_fail_request.
      
      init_fault_attr_dentries() doesn't help for mmc_fail_request.  So this
      introduces fault_create_debugfs_attr() which is able to create a
      directory in the arbitrary directory and replace
      init_fault_attr_dentries().
      
      [akpm@linux-foundation.org: extraneous semicolon, per Randy]
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Tested-by: NPer Forlin <per.forlin@linaro.org>
      Cc: Jens Axboe <axboe@kernel.dk>
      Cc: Christoph Lameter <cl@linux-foundation.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Matt Mackall <mpm@selenic.com>
      Cc: Randy Dunlap <rdunlap@xenotime.net>
      Cc: Stephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
      Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org>
      dd48c085
  7. 03 2月, 2010 1 次提交
  8. 16 6月, 2009 1 次提交
    • G
      debugfs: Fix terminology inconsistency of dir name to mount debugfs filesystem. · 156f5a78
      GeunSik Lim 提交于
      Many developers use "/debug/" or "/debugfs/" or "/sys/kernel/debug/"
      directory name to mount debugfs filesystem for ftrace according to
      ./Documentation/tracers/ftrace.txt file.
      
      And, three directory names(ex:/debug/, /debugfs/, /sys/kernel/debug/) is
      existed in kernel source like ftrace, DRM, Wireless, Documentation,
      Network[sky2]files to mount debugfs filesystem.
      
      debugfs means debug filesystem for debugging easy to use by greg kroah
      hartman. "/sys/kernel/debug/" name is suitable as directory name
      of debugfs filesystem.
      - debugfs related reference: http://lwn.net/Articles/334546/
      
      Fix inconsistency of directory name to mount debugfs filesystem.
      
      * From Steven Rostedt
        - find_debugfs() and tracing_files() in this patch.
      Signed-off-by: NGeunSik Lim <geunsik.lim@samsung.com>
      Acked-by     : Inaky Perez-Gonzalez <inaky@linux.intel.com>
      Reviewed-by  : Steven Rostedt <rostedt@goodmis.org>
      Reviewed-by  : James Smart <james.smart@emulex.com>
      CC: Jiri Kosina <trivial@kernel.org>
      CC: David Airlie <airlied@linux.ie>
      CC: Peter Osterlund <petero2@telia.com>
      CC: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      CC: Anil S Keshavamurthy <anil.s.keshavamurthy@intel.com>
      CC: Masami Hiramatsu <mhiramat@redhat.com>
      Signed-off-by: NGreg Kroah-Hartman <gregkh@suse.de>
      156f5a78
  9. 17 7月, 2007 2 次提交
  10. 09 12月, 2006 4 次提交
    • D
      [PATCH] fault-injection: Correct, disambiguate, and reformat documentation · 5d0ffa2b
      Don Mullis 提交于
      Correct, disambiguate, and reformat documentation.
      Signed-off-by: NDon Mullis <dwm@meer.net>
      Cc: Akinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      5d0ffa2b
    • A
      [PATCH] fault injection: stacktrace filtering · 329409ae
      Akinobu Mita 提交于
      This patch provides stacktrace filtering feature.
      
      The stacktrace filter allows failing only for the caller you are
      interested in.
      
      For example someone may want to inject kmalloc() failures into
      only e100 module. they want to inject not only direct kmalloc() call,
      but also indirect allocation, too.
      
      - e100_poll --> netif_receive_skb --> packet_rcv_spkt --> skb_clone
        --> kmem_cache_alloc
      
      This patch enables to detect function calls like this by stacktrace
      and inject failures. The script Documentaion/fault-injection/failmodule.sh
      helps it.
      
      The range of text section of loaded e100 is expected to be
      [/sys/module/e100/sections/.text, /sys/module/e100/sections/.exit.text)
      
      So failmodule.sh stores these values into /debug/failslab/address-start
      and /debug/failslab/address-end. The maximum stacktrace depth is specified
      by /debug/failslab/stacktrace-depth.
      
      Please see the example that demonstrates how to inject slab allocation
      failures only for a specific module
      in Documentation/fault-injection/fault-injection.txt
      
      [dwm@meer.net: reject failure if any caller lies within specified range]
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NDon Mullis <dwm@meer.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      329409ae
    • A
      [PATCH] fault-injection capability for kmalloc · 8a8b6502
      Akinobu Mita 提交于
      This patch provides fault-injection capability for kmalloc.
      
      Boot option:
      
      failslab=<interval>,<probability>,<space>,<times>
      
      	<interval> -- specifies the interval of failures.
      
      	<probability> -- specifies how often it should fail in percent.
      
      	<space> -- specifies the size of free space where memory can be
      		   allocated safely in bytes.
      
      	<times> -- specifies how many times failures may happen at most.
      
      Debugfs:
      
      /debug/failslab/interval
      /debug/failslab/probability
      /debug/failslab/specifies
      /debug/failslab/times
      /debug/failslab/ignore-gfp-highmem
      /debug/failslab/ignore-gfp-wait
      
      Example:
      
      	failslab=10,100,0,-1
      
      slab allocation (kmalloc(), kmem_cache_alloc(),..) fails once per 10 times.
      
      Cc: Pekka Enberg <penberg@cs.helsinki.fi>
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      8a8b6502
    • A
      [PATCH] fault injection: documentation and scripts · de1ba09b
      Akinobu Mita 提交于
      This patch set provides some fault-injection capabilities.
      
      - kmalloc() failures
      
      - alloc_pages() failures
      
      - disk IO errors
      
      We can see what really happens if those failures happen.
      
      In order to enable these fault-injection capabilities:
      
      1. Enable relevant config options (CONFIG_FAILSLAB, CONFIG_PAGE_ALLOC,
         CONFIG_MAKE_REQUEST) and if you want to configure them via debugfs,
         enable CONFIG_FAULT_INJECTION_DEBUG_FS.
      
      2. Build and boot with this kernel
      
      3. Configure fault-injection capabilities behavior by boot option or debugfs
      
         - Boot option
      
           failslab=
           fail_page_alloc=
           fail_make_request=
      
         - Debugfs
      
           /debug/failslab/*
           /debug/fail_page_alloc/*
           /debug/fail_make_request/*
      
         Please refer to the Documentation/fault-injection/fault-injection.txt
         for details.
      
      4. See what really happens.
      Signed-off-by: NAkinobu Mita <akinobu.mita@gmail.com>
      Signed-off-by: NDon Mullis <dwm@meer.net>
      Signed-off-by: NAndrew Morton <akpm@osdl.org>
      Signed-off-by: NLinus Torvalds <torvalds@osdl.org>
      de1ba09b