linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Masami Hiramatsu <mhiramat@kernel.org>
To: Akinobu Mita <akinobu.mita@gmail.com>
Cc: mhiramat@kernel.org, Alexei Starovoitov <ast@fb.com>,
	Josef Bacik <jbacik@fb.com>, Steven Rostedt <rostedt@goodmis.org>,
	Ingo Molnar <mingo@redhat.com>,
	"David S. Miller" <davem@davemloft.net>,
	netdev <netdev@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	ast@kernel.org, kernel-team@fb.com, daniel@iogearbox.net,
	linux-btrfs@vger.kernel.org, darrick.wong@oracle.com,
	Josef Bacik <josef@toxicpanda.com>
Subject: Re: [PATCH bpf-next v5 5/5] error-injection: Support fault injection framework
Date: Sun, 14 Jan 2018 10:06:51 +0900	[thread overview]
Message-ID: <20180114100651.d0d22c2b5a839b399fd08414@kernel.org> (raw)
In-Reply-To: <CAC5umyhf4uUM3c4YNKt=A3Zov0+ErgBt1DhsJXViYZ1hKmADfQ@mail.gmail.com>

On Sat, 13 Jan 2018 22:28:29 +0900
Akinobu Mita <akinobu.mita@gmail.com> wrote:

> 2018-01-13 2:56 GMT+09:00 Masami Hiramatsu <mhiramat@kernel.org>:
> > Support in-kernel fault-injection framework via debugfs.
> > This allows you to inject a conditional error to specified
> > function using debugfs interfaces.
> >
> > Here is the result of test script described in
> > Documentation/fault-injection/fault-injection.txt
> >
> >   ===========
> >   # ./test_fail_function.sh
> >   1+0 records in
> >   1+0 records out
> >   1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0227404 s, 46.1 MB/s
> >   btrfs-progs v4.4
> >   See http://btrfs.wiki.kernel.org for more information.
> >
> >   Label:              (null)
> >   UUID:               bfa96010-12e9-4360-aed0-42eec7af5798
> >   Node size:          16384
> >   Sector size:        4096
> >   Filesystem size:    1001.00MiB
> >   Block group profiles:
> >     Data:             single            8.00MiB
> >     Metadata:         DUP              58.00MiB
> >     System:           DUP              12.00MiB
> >   SSD detected:       no
> >   Incompat features:  extref, skinny-metadata
> >   Number of devices:  1
> >   Devices:
> >      ID        SIZE  PATH
> >       1  1001.00MiB  /dev/loop2
> >
> >   mount: mount /dev/loop2 on /opt/tmpmnt failed: Cannot allocate memory
> >   SUCCESS!
> >   ===========
> >
> >
> > Signed-off-by: Masami Hiramatsu <mhiramat@kernel.org>
> > Reviewed-by: Josef Bacik <jbacik@fb.com>
> > ---
> >   Changes in v3:
> >    - Check and adjust error value for each target function
> >    - Clear kporbe flag for reuse
> >    - Add more documents and example
> >   Changes in v5:
> >    - Support multi-function error injection
> > ---
> >  Documentation/fault-injection/fault-injection.txt |   68 ++++
> >  kernel/Makefile                                   |    1
> >  kernel/fail_function.c                            |  349 +++++++++++++++++++++
> >  lib/Kconfig.debug                                 |   10 +
> >  4 files changed, 428 insertions(+)
> >  create mode 100644 kernel/fail_function.c
> >
> > diff --git a/Documentation/fault-injection/fault-injection.txt b/Documentation/fault-injection/fault-injection.txt
> > index 918972babcd8..f4a32463ca48 100644
> > --- a/Documentation/fault-injection/fault-injection.txt
> > +++ b/Documentation/fault-injection/fault-injection.txt
> > @@ -30,6 +30,12 @@ o fail_mmc_request
> >    injects MMC data errors on devices permitted by setting
> >    debugfs entries under /sys/kernel/debug/mmc0/fail_mmc_request
> >
> > +o fail_function
> > +
> > +  injects error return on specific functions, which are marked by
> > +  ALLOW_ERROR_INJECTION() macro, by setting debugfs entries
> > +  under /sys/kernel/debug/fail_function. No boot option supported.
> > +
> >  Configure fault-injection capabilities behavior
> >  -----------------------------------------------
> >
> > @@ -123,6 +129,29 @@ configuration of fault-injection capabilities.
> >         default is 'N', setting it to 'Y' will disable failure injections
> >         when dealing with private (address space) futexes.
> >
> > +- /sys/kernel/debug/fail_function/inject:
> > +
> > +       Format: { 'function-name' | '!function-name' | '' }
> > +       specifies the target function of error injection by name.
> > +       If the function name leads '!' prefix, given function is
> > +       removed from injection list. If nothing specified ('')
> > +       injection list is cleared.
> > +
> > +- /sys/kernel/debug/fail_function/injectable:
> > +
> > +       (read only) shows error injectable functions and what type of
> > +       error values can be specified. The error type will be one of
> > +       below;
> > +       - NULL: retval must be 0.
> > +       - ERRNO: retval must be -1 to -MAX_ERRNO (-4096).
> > +       - ERR_NULL: retval must be 0 or -1 to -MAX_ERRNO (-4096).
> > +
> > +- /sys/kernel/debug/fail_function/<functiuon-name>/retval:
> > +
> > +       specifies the "error" return value to inject to the given
> > +       function for given function. This will be created when
> > +       user specifies new injection entry.
> > +
> >  o Boot option
> >
> >  In order to inject faults while debugfs is not available (early boot time),
> > @@ -268,6 +297,45 @@ trap "echo 0 > /sys/kernel/debug/$FAILTYPE/probability" SIGINT SIGTERM EXIT
> >  echo "Injecting errors into the module $module... (interrupt to stop)"
> >  sleep 1000000
> >
> > +------------------------------------------------------------------------------
> > +
> > +o Inject open_ctree error while btrfs mount
> > +
> > +#!/bin/bash
> > +
> > +rm -f testfile.img
> > +dd if=/dev/zero of=testfile.img bs=1M seek=1000 count=1
> > +DEVICE=$(losetup --show -f testfile.img)
> > +mkfs.btrfs -f $DEVICE
> > +mkdir -p tmpmnt
> > +
> > +FAILTYPE=fail_function
> > +FAILFUNC=open_ctree
> > +echo $FAILFUNC > /sys/kernel/debug/$FAILTYPE/inject
> > +echo -12 > /sys/kernel/debug/$FAILTYPE/$FAILFUNC/retval
> > +echo N > /sys/kernel/debug/$FAILTYPE/task-filter
> > +echo 100 > /sys/kernel/debug/$FAILTYPE/probability
> > +echo 0 > /sys/kernel/debug/$FAILTYPE/interval
> > +echo -1 > /sys/kernel/debug/$FAILTYPE/times
> > +echo 0 > /sys/kernel/debug/$FAILTYPE/space
> > +echo 1 > /sys/kernel/debug/$FAILTYPE/verbose
> 
> I expected that the fault_attr is created for each target function.
> (i.e. /sys/kernel/debug/fail_function/<func>/ directory contains not
> only 'retval', but also 'probability', 'interval', ...)
> 
> Or is there any good reason to share a single fault_attr for all
> error injected functions?

Good question. I actually considered that. But since fault-attr only
considers no relationship between 2 fault points (in time too),
this means each time should_fail() will be done as independent trial.
So, in most case user will just copy the setting for those 2 points.
(another reason is not to change the document so much :), all interface
are still under /sys/kernel/debug/fail_*/ ...)

Thank you,

-- 
Masami Hiramatsu <mhiramat@kernel.org>

  reply	other threads:[~2018-01-14  1:06 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-12 17:53 [PATCH bpf-next v5 0/5] Separate error injection table from kprobes Masami Hiramatsu
2018-01-12 17:54 ` [PATCH bpf-next v5 1/5] tracing/kprobe: bpf: Check error injectable event is on function entry Masami Hiramatsu
2018-01-12 17:54 ` [PATCH bpf-next v5 2/5] tracing/kprobe: bpf: Compare instruction pointer with original one Masami Hiramatsu
2018-01-12 17:55 ` [PATCH bpf-next v5 3/5] error-injection: Separate error-injection from kprobe Masami Hiramatsu
2018-01-12 17:55 ` [PATCH bpf-next v5 4/5] error-injection: Add injectable error types Masami Hiramatsu
2018-01-12 17:56 ` [PATCH bpf-next v5 5/5] error-injection: Support fault injection framework Masami Hiramatsu
2018-01-13 13:28   ` Akinobu Mita
2018-01-14  1:06     ` Masami Hiramatsu [this message]
2018-01-13  1:52 ` [PATCH bpf-next v5 0/5] Separate error injection table from kprobes Alexei Starovoitov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180114100651.d0d22c2b5a839b399fd08414@kernel.org \
    --to=mhiramat@kernel.org \
    --cc=akinobu.mita@gmail.com \
    --cc=ast@fb.com \
    --cc=ast@kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=darrick.wong@oracle.com \
    --cc=davem@davemloft.net \
    --cc=jbacik@fb.com \
    --cc=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=rostedt@goodmis.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).