From: Chris Mason <chris.mason@oracle.com>
To: Pavel Machek <pavel@suse.cz>
Cc: Christoph Hellwig <hch@infradead.org>,
Eric Sesterhenn <snakebyte@gmx.de>,
linux-kernel@vger.kernel.org, linux-btrfs@vger.kernel.org
Subject: Re: Warning and BUG with btrfs and corrupted image
Date: Thu, 05 Feb 2009 08:02:39 -0500 [thread overview]
Message-ID: <1233838959.15948.6.camel@think.oraclecorp.com> (raw)
In-Reply-To: <20090205090229.GA2011@elf.ucw.cz>
On Thu, 2009-02-05 at 10:02 +0100, Pavel Machek wrote:
> > > > CONFIG_*_DEBUG means include *debug* code there to help developers,
> > > > including adding additional failure tests into the kernel. Besides,
> > > > which bit of "don't turn it on unless you are an XFS developer"
> > > > don't you understand?
> > >
> > > Yes, but DEBUG code is normally to help debugging, not to crash
> > > kernels.
> >
> > Crashing the kernel at exactly the point a problem is detected
> > is often the simplest way of debugging the problem.
> >
> > e.g. CONFIG_VM_DEBUG=y turns on VM_BUG_ON() which crashes the kernel
> > whenever it detects something wrong. Do I turn it on? Yes. Do i
>
> That's different. User is not supposed to be able to trigger
> VM_BUG_ON().
>
> > complain about it when I hit a VM_BUG_ON()? No, I report the
> > bug and move on. If you turn on a DEBUG option, then you are
> > asking the system to behave in a way useful to a developer,
> > not an end user. That includes panicing when something wrong
> > is detected.
>
> Imagine vm going panic() on mkdir("/lost+found")...
It is up to the XFS developers to decide what their debugging options
do.
The whole point of panicing is so that you can collect important
information about the system at the time of the error condition. When
this option is compiled on, panic on mkdir is exactly what they are
asking for.
If you don't want it, don't compile it in. The Kconfig text is very
clear.
-chris
next prev parent reply other threads:[~2009-02-05 13:03 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-01-13 14:21 Warning and BUG with btrfs and corrupted image Eric Sesterhenn
2009-01-13 14:40 ` Chris Mason
2009-01-13 14:43 ` Eric Sesterhenn
2009-01-15 2:13 ` Chris Mason
2009-01-18 17:40 ` Pavel Machek
2009-01-20 6:31 ` Eric Sesterhenn
2009-01-20 9:34 ` Pavel Machek
2009-01-20 10:11 ` Dave Chinner
2009-01-20 10:15 ` Eric Sesterhenn
2009-01-20 12:59 ` Dave Chinner
2009-01-20 13:28 ` Christoph Hellwig
2009-01-20 22:20 ` Pavel Machek
2009-01-21 4:00 ` Dave Chinner
2009-01-26 16:27 ` Pavel Machek
2009-02-01 1:40 ` Dave Chinner
2009-02-04 18:29 ` Pavel Machek
2009-02-05 8:59 ` Dave Chinner
2009-02-05 9:02 ` Pavel Machek
2009-02-05 13:02 ` Chris Mason [this message]
2009-02-05 13:50 ` Pavel Machek
2009-02-05 14:19 ` jim owens
2009-02-25 19:54 ` Pavel Machek
2009-01-20 17:34 ` Eric Sesterhenn
2009-01-20 22:18 ` Pavel Machek
2009-01-21 9:36 ` Eric Sesterhenn
2009-01-21 3:57 ` Corrupted XFS log replay oops. (was Re: Warning and BUG with btrfs and corrupted image) Dave Chinner
2009-01-21 4:03 ` Nick Piggin
2009-01-22 4:37 ` [PATCH] Re: Corrupted XFS log replay oops Dave Chinner
2009-01-22 5:50 ` Felix Blyakher
2009-01-22 6:11 ` Christoph Hellwig
2009-01-22 8:35 ` Eric Sesterhenn
2009-01-22 10:06 ` Eric Sesterhenn
2009-01-22 23:37 ` Dave Chinner
2009-01-23 1:10 ` Dave Chinner
2009-01-22 23:35 ` Dave Chinner
2009-01-23 0:02 ` Dave Chinner
2009-01-23 0:06 ` Christoph Hellwig
2009-01-23 6:20 ` Felix Blyakher
2009-01-21 4:03 ` Corrupted XFS log replay oops. (was Re: Warning and BUG with btrfs and corrupted image) Dave Chinner
2009-01-20 13:11 ` Warning and BUG with btrfs and corrupted image Chris Mason
2009-01-20 16:51 ` Eric Sesterhenn
2009-01-22 2:15 ` Phillip Lougher
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=1233838959.15948.6.camel@think.oraclecorp.com \
--to=chris.mason@oracle.com \
--cc=hch@infradead.org \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=pavel@suse.cz \
--cc=snakebyte@gmx.de \
/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