From: Josef Bacik <josef@redhat.com>
To: Yoshinori Sano <yoshinori.sano@gmail.com>
Cc: josef@redhat.com, chris.mason@oracle.com, linux-btrfs@vger.kernel.org
Subject: Re: On Removing BUG_ON macros
Date: Mon, 8 Nov 2010 08:28:44 -0500 [thread overview]
Message-ID: <20101108132844.GA2515@localhost.localdomain> (raw)
In-Reply-To: <AANLkTinjy4HDf+74uTLo+zVqM0WqsvZUMjgw7Hv+jdLN@mail.gmail.com>
On Mon, Nov 08, 2010 at 10:17:50PM +0900, Yoshinori Sano wrote:
> To reduce the number of such BUG_ON usages, the code will be more robust,
> which results in increasing the number of Btrfs production use.
> (This is one of the way, off course.)
>
> But, as you pointed out, removing such BUG_ONs is tricky...
>
> > static int foo = 1;
> >
> > path = btrfs_alloc_path();
> > if (!path || !(foo % 1000))
> > return -ENOMEM;
> > foo++;
>
> Is this a debugging idiom?
> I cannot understand why this idiom can be used to catch all the callers.
> Would you explain more about it?
>
So this forces us to return the error case every 1000 times the function is
called. So you can run various tests that stress the FS in different ways so
you can catch alot of the possible ways you can end up in this function. Then
if any of the callers have problems getting ENOMEM then the box will panic or
something like that and you can fix the callers. Then when the system stops
panicing/blowing up after a while you know you are pretty OK with returning
ENOMEM in this case and you can post the patch and move on to the next one.
But as Ian says it gets a little confusing in the more complicated cases, so you
are probably better off walking up the possible callchains by hand and fixing
any problems you see, and then doing the above to validate your work. Thanks,
Josef
next prev parent reply other threads:[~2010-11-08 13:28 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-07 7:16 On Removing BUG_ON macros Yoshinori Sano
2010-11-07 14:51 ` Josef Bacik
2010-11-08 2:54 ` Ian Kent
2010-11-08 12:42 ` Josef Bacik
2010-11-08 14:06 ` Ian Kent
2010-11-08 14:15 ` Josef Bacik
2010-11-08 15:02 ` Ian Kent
2010-11-11 4:32 ` Ian Kent
2010-12-01 18:31 ` Josef Bacik
2010-11-09 6:13 ` Yoshinori Sano
2010-11-08 13:17 ` Yoshinori Sano
2010-11-08 13:28 ` Josef Bacik [this message]
2010-11-08 23:02 ` Yoshinori Sano
2010-11-08 2:36 ` Ian Kent
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=20101108132844.GA2515@localhost.localdomain \
--to=josef@redhat.com \
--cc=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=yoshinori.sano@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).