Re: [PATCH] Btrfs: add support for asserts

[Jeff Mahoney <jeffm@suse.com>]

[-- Attachment #1: Type: text/plain, Size: 4567 bytes --]

On 8/27/13 5:28 PM, Eric Sandeen wrote:
> On 8/27/13 4:25 PM, Jeff Mahoney wrote:
>> On 8/27/13 5:21 PM, Eric Sandeen wrote:
>>> On 8/27/13 4:07 PM, Jeff Mahoney wrote:
>>>> On 8/27/13 4:56 PM, Josef Bacik wrote:
>>>>> On Tue, Aug 27, 2013 at 03:28:24PM -0400, Jeff Mahoney wrote:
>>>>>> On 8/26/13 4:56 PM, Josef Bacik wrote:
>>>>>>> One of the complaints we get a lot is how many BUG_ON()'s we have.  So to help
>>>>>>> with this I'm introducing a kconfig option to enable/disable a new ASSERT()
>>>>>>> mechanism much like what XFS does.  This will allow us developers to still get
>>>>>>> our nice panics but allow users/distros to compile them out.  With this we can
>>>>>>> go through and convert any BUG_ON()'s that we have to catch actual programming
>>>>>>> mistakes to the new ASSERT() and then fix everybody else to return errors.  This
>>>>>>> will also allow developers to leave sanity checks in their new code to make sure
>>>>>>> we don't trip over problems while testing stuff and vetting new features.
>>>>>>> Thanks,
>>>>>>
>>>>>> I don't think the complaint is so much about the number of BUG_ONs, but
>>>>>> that there's no distinction between something that is supposed to be
>>>>>> impossible and something that is improbable. The BUG_ONs to keep code
>>>>>> correctness are good and are littered all over the kernel with positive
>>>>>> results. The BUG_ONs that are there in place of real error handling
>>>>>> served their purpose and need to be replaced.
>>>>>>
>>>>>> So, I don't know if it's a net win to compile the "good" BUG_ONs out of
>>>>>> the code. Especially if a user runs into something strange yet familiar
>>>>>> and the first response is "oh, huh, can you rebuild with asserts enabled?"
>>>>>>
>>>>>
>>>>> Either I provide an option for it or distros do it themselves, this cuts out the
>>>>> middle man.  I'd really rather they just be on all the time since they aren't
>>>>> things we should hit anyway, but at least this way people have a choice.
>>>
>>>> Ok. With my distro hat on, I can tell you I'll be leaving them on. :)
>>>
>>>> -Jeff
>>>
>>> XFS also has XFS_WARN as a config option, which keeps all the assertions
>>> in place, but printk's & backtraces w/o the icky BUG().  That might be
>>> good to add as well, and perhaps best for a shipping distro (vs. a developer
>>> debugging who might want to drop a core file when the assert trips).
> 
>> Isn't that the distinction between BUG_ON and WARN_ON? If it's worth a
>> BUG_ON, things should be bad enough (or could result in being bad
>> enough) that we want to bail out.
> 
>> -Jeff
> 
> Maybe; just FWIW here was Dave's rationale for xfs.  Right now btrfs
> doesn't have the behavior-changing side effect (no BTRFS_DEBUG config)
> though, so maybe the distinction is less important...

Yeah, I'd agree with the distinction not being there in btrfs (yet).
ReiserFS has a similar mode where there are a ton of checks that are
optionally enabled and does invasive things that can slow things down.
It's disabled pretty much universally AFAIK. One of the things (low) on
my TODO list is to go through all of those and move them into regular
checks since some of them are the types of things fsfuzzer likes to trip
over.

-Jeff

>     xfs: introduce CONFIG_XFS_WARN
>     
>     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@redhat.com>
> 
> 
> 

-- 
Jeff Mahoney
SUSE Labs


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 841 bytes --]