public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Sandeen <sandeen@sandeen.net>
To: Sebastian Siewior <lkml@ml.breakpoint.cc>
Cc: Dave Chinner <david@fromorbit.com>,
	Mikael Abrahamsson <swmike@swm.pp.se>,
	linux-kernel@vger.kernel.org, xfs@oss.sgi.com
Subject: Re: xfs bug in 2.6.26-rc9
Date: Fri, 11 Jul 2008 14:52:37 -0500	[thread overview]
Message-ID: <4877BA05.4000109@sandeen.net> (raw)
In-Reply-To: <20080711190209.GA7401@Chamillionaire.breakpoint.cc>

Sebastian Siewior wrote:
> * Dave Chinner | 2008-07-11 18:42:49 [+1000]:
> 
>> Oh - you must be running a debug XFS.  CONFIG_XFS_DEBUG was only
>> introduced in 2.6.26-rc1 and defaults to 'N', so you must have
>> selected the non-default option when prompted. This will cause your
>> machine to oops at the slightest inconsistency that is found,
>> regardless of whether it is fatal or not. Like the help text says,
>> don't set this unless you are an XFS developer....
> Could you please add this to the Kconfig entry. Debug mode is usually
> noisy, little slower and mostly usefull just to the developers but *I*
> would not expect to BUG() in the non-fatal case.
> Not sure but if this is just for hch and you than a define in xfs.h
> might be safer :)
> 
>> Dave.
> Sebastian
> 
> 

heh, it ws hch who added the Kconfig option in the first place :)

> Back when I first submitted XFS for mainline inclusion we made the
> decision that the debug code is far to extensive to be accidentally
> enabled by users in mainline.  But then again it's often quite useful
> to track problems down and hacking the makefile all the time is rather
> annoying.  Given all the debug options with even more overhead like
> lockdep or DEBUG_PAGE_ALLOC users (or rather developers) should know
> by now what they're doing.
> 
> 
> Signed-off-by: Christoph Hellwig <hch@lst.de>

But yeah, a bit more of a stern warning about the fatality of the debug
tests might be useful.  Just in case anyone reads that part and not the
"only use this if you are an xfs developer" part ;)

-Eric


  reply	other threads:[~2008-07-11 19:52 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-07-11  7:46 xfs bug in 2.6.26-rc9 Mikael Abrahamsson
2008-07-11  8:42 ` Dave Chinner
2008-07-11 10:21   ` Mikael Abrahamsson
2008-07-14  7:30     ` Dave Chinner
2008-07-14  8:16       ` Mikael Abrahamsson
2008-07-14  7:34     ` Lachlan McIlroy
2008-07-14 12:13       ` Dave Chinner
2008-07-15  2:12         ` Lachlan McIlroy
2008-07-15  3:18           ` Dave Chinner
2008-07-15  6:17         ` Nick Piggin
2008-07-15 12:22           ` Christoph Hellwig
2008-07-16  4:12             ` Nick Piggin
2008-07-11 19:02   ` Sebastian Siewior
2008-07-11 19:52     ` Eric Sandeen [this message]
2008-07-11 23:22     ` Dave Chinner
2008-07-12  5:06       ` Sebastian Siewior

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=4877BA05.4000109@sandeen.net \
    --to=sandeen@sandeen.net \
    --cc=david@fromorbit.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lkml@ml.breakpoint.cc \
    --cc=swmike@swm.pp.se \
    --cc=xfs@oss.sgi.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox