From: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
To: Stefan Behrens <sbehrens@giantdisaster.de>
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] Btrfs: cleanup of error processing in btree_get_extent()
Date: Thu, 13 Sep 2012 10:08:24 +0900 [thread overview]
Message-ID: <50513208.3010202@jp.fujitsu.com> (raw)
In-Reply-To: <505065FB.4040200@giantdisaster.de>
Hi, Stefan,
(2012/09/12 19:37), Stefan Behrens wrote:
> On Wed, 12 Sep 2012 17:26:43 +0900, Tsutomu Itoh wrote:
>> This patch simplifies a little complex error processing in
>> btree_get_extent().
>>
>> Signed-off-by: Tsutomu Itoh <t-itoh@jp.fujitsu.com>
>> ---
>> fs/btrfs/disk-io.c | 14 +++++---------
>> 1 files changed, 5 insertions(+), 9 deletions(-)
>>
>> diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
>> index 29c69e6..27d0ebe 100644
>> --- a/fs/btrfs/disk-io.c
>> +++ b/fs/btrfs/disk-io.c
>> @@ -222,21 +222,17 @@ static struct extent_map *btree_get_extent(struct inode *inode,
>>
>> free_extent_map(em);
>> em = lookup_extent_mapping(em_tree, start, len);
>> - if (em) {
>> - ret = 0;
>> - } else {
>> - em = lookup_extent_mapping(em_tree, failed_start,
>> - failed_len);
>> - ret = -EIO;
>> + if (!em) {
>> + lookup_extent_mapping(em_tree, failed_start,
>> + failed_len);
>> + em = ERR_PTR(-EIO);
>
> The patch itself looks good and doesn't change the behavior while it
> simplifies the code. But I think that it identifies an old error in the
> code. It is eye-catching the the return value of lookup_extent_mapping()
> is not used. Therefore the call can either be removed or it has
> side-effects which are required. lookup_extent_mapping() has the
> side-effect to increment the extent map's ref count that it returns. I
> cannot believe that this incremented ref count is correct when the
> extent map itself is not used. IMO, either the EIO and ignoring the
> returned extent map is wrong, or the incremented ref count is wrong.
Thank you for your review.
I think lookup_extent_mapping() using failed_start is not needed.
So, I will remake my patch later.
Thanks,
Tsutomu
>
>> }
>> } else if (ret) {
>> free_extent_map(em);
>> - em = NULL;
>> + em = ERR_PTR(ret);
>> }
>> write_unlock(&em_tree->lock);
>>
>> - if (ret)
>> - em = ERR_PTR(ret);
>> out:
>> return em;
>> }
>
>
>
prev parent reply other threads:[~2012-09-13 1:08 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-12 8:26 [PATCH] Btrfs: cleanup of error processing in btree_get_extent() Tsutomu Itoh
2012-09-12 10:37 ` Stefan Behrens
2012-09-13 1:08 ` Tsutomu Itoh [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=50513208.3010202@jp.fujitsu.com \
--to=t-itoh@jp.fujitsu.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=sbehrens@giantdisaster.de \
/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.