xfs
[Top] [All Lists]

Re: [PATCH 2/4] xfs: introduce CONFIG_XFS_WARN

To: Dave Chinner <david@xxxxxxxxxxxxx>
Subject: Re: [PATCH 2/4] xfs: introduce CONFIG_XFS_WARN
From: Ben Myers <bpm@xxxxxxx>
Date: Tue, 7 May 2013 19:02:22 -0500
Cc: xfs@xxxxxxxxxxx
Delivered-to: xfs@xxxxxxxxxxx
In-reply-to: <1367321976-18268-3-git-send-email-david@xxxxxxxxxxxxx>
References: <1367321976-18268-1-git-send-email-david@xxxxxxxxxxxxx> <1367321976-18268-3-git-send-email-david@xxxxxxxxxxxxx>
User-agent: Mutt/1.5.20 (2009-06-14)
On Tue, Apr 30, 2013 at 09:39:34PM +1000, Dave Chinner wrote:
> From: Dave Chinner <dchinner@xxxxxxxxxx>
> 
> Running a CONFIG_XFS_DEBUG kernel in production environments is not
> the best idea as it introduces significant overhead, can change
> the behaviour of algorithms (such as allocation) to improve test
> coverage, and (most importantly) panic the machine on non-fatal
> errors.
> 
> There are many cases where all we want to do is run a
> kernel with more bounds checking enabled, such as is provided by the
> ASSERT() statements throughout the code, but without all the
> potential overhead and drawbacks.
> 
> This patch converts all the ASSERT statements to evaluate as
> WARN_ON(1) statements and hence if they fail dump a warning and a
> stack trace to the log. This has minimal overhead and does not
> change any algorithms, and will allow us to find strange "out of
> bounds" problems more easily on production machines.
> 
> There are a few places where assert statements contain debug only
> code. These are converted to be debug-or-warn only code so that we
> still get all the assert checks in the code.
> 
> Signed-off-by: Dave Chinner <dchinner@xxxxxxxxxx>

Applied.

<Prev in Thread] Current Thread [Next in Thread>
  • Re: [PATCH 2/4] xfs: introduce CONFIG_XFS_WARN, Ben Myers <=