From: Chris Mason <chris.mason@oracle.com>
To: liubo <liubo2009@cn.fujitsu.com>
Cc: Linux Btrfs <linux-btrfs@vger.kernel.org>
Subject: Re: [fnst-kernel 10816] Found several problems while reading btrfs code
Date: Thu, 28 Oct 2010 09:03:16 -0400 [thread overview]
Message-ID: <20101028130316.GX27796@think> (raw)
In-Reply-To: <4CC7D75D.3050806@cn.fujitsu.com>
On Wed, Oct 27, 2010 at 03:40:13PM +0800, liubo wrote:
> Hi, Chris,
>
> We've found several tiny problems while reading btrfs code.
>
> These problems are mainly about uncheck return value or BUG_ON check.
> They really have an impact on codes' quality, though they will not be
> hit in normal cases.
>
> Here comes some examples:
>
> 1. memory allocation check
> May cause -ENOMEM, btrfs BUG_ON().
>
> static int alloc_reserved_file_extent(struct btrfs_trans_handle *trans,
> ...
> path = btrfs_alloc_path();
> BUG_ON(!path);
Yes we should either use GFP_NOFAIL or we should deal with the error
nicely.
>
> 2. return value's BUG_ON() check
>
> static noinline int update_ref_for_cow(struct btrfs_trans_handle *trans,
> ...
> if (btrfs_block_can_be_shared(root, buf)) {
> ret = btrfs_lookup_extent_info(trans, root, buf->start,
> buf->len, &refs, &flags);
> BUG_ON(ret);
> BUG_ON(refs == 0);
>
>
>
> Is there a plan to improve the above?
> We are helpful on this:)
Definitely. The first step is to find the errors that can just be
dealt with. After that we need to make a way to force the FS into a
readonly state for the really impossible ones.
Both are very good projects ;)
-chris
prev parent reply other threads:[~2010-10-28 13:03 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-27 7:40 [fnst-kernel 10816] Found several problems while reading btrfs code liubo
2010-10-28 13:03 ` Chris Mason [this message]
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=20101028130316.GX27796@think \
--to=chris.mason@oracle.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=liubo2009@cn.fujitsu.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.