From: Artem Bityutskiy <dedekind1@gmail.com>
To: "Américo Wang" <xiyou.wangcong@gmail.com>
Cc: Simon Kagstrom <simon.kagstrom@netinsight.net>,
linux-kernel@vger.kernel.org,
David Woodhouse <dwmw2@infradead.org>,
Ingo Molnar <mingo@elte.hu>
Subject: Re: [PATCH] Provide ways of crashing the kernel through debugfs
Date: Thu, 28 Jan 2010 16:38:02 +0200 [thread overview]
Message-ID: <1264689482.1973.132.camel@localhost> (raw)
In-Reply-To: <2375c9f91001261853t1158a66aw86546a61e613338f@mail.gmail.com>
On Wed, 2010-01-27 at 10:53 +0800, Américo Wang wrote:
> On Tue, Jan 26, 2010 at 6:18 PM, Simon Kagstrom
> <simon.kagstrom@netinsight.net> wrote:
> > Hi Americo!
> >
> > On Tue, 26 Jan 2010 18:08:28 +0800
> > Américo Wang <xiyou.wangcong@gmail.com> wrote:
> >
> >> On Tue, Jan 26, 2010 at 5:56 PM, Simon Kagstrom
> >> <simon.kagstrom@netinsight.net> wrote:
> >> > For development and testing it's sometimes useful to crash or injure the
> >> > kernel in various ways. This patch adds a debugfs interface to provoke
> >> > null-pointer dereferences, stack corruption, panics, bugons etc. For
> >> > example:
> >> >
> >> > mount -t debugfs debugfs /mnt
> >> > echo 1 > /mnt/provoke-crash/null_dereference
> >> >
> >> > Signed-off-by: Simon Kagstrom <simon.kagstrom@netinsight.net>
> >> > ---
> >> > Obviously this feature is for debugging and testing only, and of
> >> > interest to fairly few people. I've used it for testing the kmsg_dump
> >> > stuff (hence the CC:s above) and kdump, and have found it fairly useful.
> >> >
> >> > If it's not of interest, at least this mail will be in the archives if
> >> > someone else needs something like it :-)
> >>
> >> Hey, we already have /proc/sysrq-trigger, you need to state why
> >> it is better than using /proc/sysrq-trigger.
> >
> > Well, it provides a few more ways of crashing the kernel. That's
> > basically the only additional feature you'll get.
> >
>
> Yeah, I can see that, but why do I need to care how I crash the kernel
> as long as I can crash it in a way.
But Simon did explain in his first e-mail why he cares. You or others
might care for similar reasons.
--
Best Regards,
Artem Bityutskiy (Артём Битюцкий)
next prev parent reply other threads:[~2010-01-28 14:39 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-26 9:56 [PATCH] Provide ways of crashing the kernel through debugfs Simon Kagstrom
2010-01-26 10:08 ` Américo Wang
2010-01-26 10:18 ` Simon Kagstrom
2010-01-27 2:53 ` Américo Wang
2010-01-27 7:09 ` Simon Kagstrom
2010-01-28 14:38 ` Artem Bityutskiy [this message]
2010-01-29 6:13 ` Simon Kagstrom
2010-01-29 10:33 ` Andrew Morton
2010-02-02 4:16 ` Eric W. Biederman
2010-02-02 8:16 ` Simon Kagstrom
2010-02-03 8:52 ` [PATCH] lkdtm: Add debugfs access and loosen KPROBE ties Simon Kagstrom
2010-02-03 22:55 ` Andrew Morton
2010-02-04 9:06 ` [PATCH v2] " Simon Kagstrom
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=1264689482.1973.132.camel@localhost \
--to=dedekind1@gmail.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=simon.kagstrom@netinsight.net \
--cc=xiyou.wangcong@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.