From: Qu Wenruo <quwenruo@cn.fujitsu.com>
To: Zhao Lei <zhaolei@cn.fujitsu.com>, <dsterba@suse.com>,
<clm@fb.com>, <anand.jain@oracle.com>, <fdmanana@suse.com>,
<linux-btrfs@vger.kernel.org>, <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree.
Date: Wed, 7 Sep 2016 09:56:40 +0800 [thread overview]
Message-ID: <f23134aa-435d-e280-e35f-402c8acb8093@cn.fujitsu.com> (raw)
In-Reply-To: <20160907013843.GA3907@linux-zmni.apac.novell.com>
At 09/07/2016 09:38 AM, Sean Fu wrote:
> On Mon, Sep 05, 2016 at 03:56:41PM +0800, Qu Wenruo wrote:
>>
>>
>> At 09/05/2016 09:19 AM, Zhao Lei wrote:
>>> Hi, Sean Fu
>>>
>>>> From: Sean Fu [mailto:fxinrong@gmail.com]
>>>> Sent: Sunday, September 04, 2016 7:54 PM
>>>> To: dsterba@suse.com
>>>> Cc: clm@fb.com; anand.jain@oracle.com; fdmanana@suse.com;
>>>> zhaolei@cn.fujitsu.com; linux-btrfs@vger.kernel.org;
>>>> linux-kernel@vger.kernel.org; Sean Fu <fxinrong@gmail.com>
>>>> Subject: [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in
>>>> btrfs_read_chunk_tree.
>>>>
>>>> The input argument root is already set with "fs_info->chunk_root".
>>>> "chunk_root = fs_info->chunk_root = btrfs_alloc_root(fs_info)" in caller
>>>> "open_ctree".
>>>> “root->fs_info = fs_info” in "btrfs_alloc_root".
>>>>
>>> The root argument of this function means "any root".
>>> And the function is designed getting chunk root from
>>> "any root" in head.
>>>
>>> Since there is only one caller of this function,
>>> and the caller always send chunk_root as root argument in
>>> current code, we can remove above conversion,
>>> and I suggest renaming root to chunk_root to make it clear,
>>> something like:
>>>
>>> - btrfs_read_chunk_tree(struct btrfs_root *root)
>>> + btrfs_read_chunk_tree(struct btrfs_root *chunk_root)
>>
>> Since root is only used to get fs_info->chunk_root, why not use fs_info
>> directly?
> Sorry for late reply.
> chunk_root is processed in btrfs_read_chunk_tree.
> Why should we pass fs_info directly to btrfs_read_chunk_tree?
> Could you give me more detail?
>
> Many thanks
Normally we should only pass btrfs_root as parameter if it's a
file/log/relocation tree which can't be grabbed directly from fs_info.
For system wide trees, which are already in fs_info, like
fs_info->extent_root/chunk_root/..., we should pass fs_info.
Which is much much safer than passing a btrfs_root.
Careless caller can pass wrong tree and cause undefined behavior.
And such behavior makes caller more aware of what they really want to do.
Cases like just to grab sectorsize/nodesize shouldn't need a full
btrfs_root.
(Jeff's patchset has already done such things quite well)
Thanks,
Qu
>>
>> Thanks,
>> Qu
>>
>>>
>>> Thanks
>>> Zhaolei
>>>
>>>> Signed-off-by: Sean Fu <fxinrong@gmail.com>
>>>> ---
>>>> fs/btrfs/volumes.c | 2 --
>>>> 1 file changed, 2 deletions(-)
>>>>
>>>> diff --git a/fs/btrfs/volumes.c b/fs/btrfs/volumes.c
>>>> index 366b335..384a6d2 100644
>>>> --- a/fs/btrfs/volumes.c
>>>> +++ b/fs/btrfs/volumes.c
>>>> @@ -6600,8 +6600,6 @@ int btrfs_read_chunk_tree(struct btrfs_root *root)
>>>> int ret;
>>>> int slot;
>>>>
>>>> - root = root->fs_info->chunk_root;
>>>> -
>>>> path = btrfs_alloc_path();
>>>> if (!path)
>>>> return -ENOMEM;
>>>> --
>>>> 2.6.2
>>>>
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
prev parent reply other threads:[~2016-09-07 1:57 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1472990010-10707-1-git-send-email-fxinrong@gmail.com>
2016-09-05 1:19 ` [PATCH] Btrfs: remove unnecessary code of chunk_root assignment in btrfs_read_chunk_tree Zhao Lei
2016-09-05 7:56 ` Qu Wenruo
2016-09-06 2:41 ` Zhao Lei
2016-09-06 3:05 ` Jeff Mahoney
2016-09-06 3:13 ` Jeff Mahoney
2016-09-06 9:58 ` David Sterba
2016-09-06 15:12 ` Jeff Mahoney
2016-09-07 1:44 ` Sean Fu
2016-09-09 3:08 ` Sean Fu
2016-09-09 3:25 ` Jeff Mahoney
2016-09-09 3:45 ` Sean Fu
2016-09-10 15:58 ` Sean Fu
2016-09-10 16:01 ` Jeff Mahoney
2016-09-07 1:38 ` Sean Fu
2016-09-07 1:56 ` Qu Wenruo [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=f23134aa-435d-e280-e35f-402c8acb8093@cn.fujitsu.com \
--to=quwenruo@cn.fujitsu.com \
--cc=anand.jain@oracle.com \
--cc=clm@fb.com \
--cc=dsterba@suse.com \
--cc=fdmanana@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=zhaolei@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox