From: Nikolay Borisov <nborisov@suse.com>
To: dsterba@suse.cz, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs: Factor out read portion of btrfs_get_blocks_direct
Date: Wed, 11 Apr 2018 10:22:58 +0300 [thread overview]
Message-ID: <e68cd719-3a3c-b125-eed0-97bf7f1afb08@suse.com> (raw)
In-Reply-To: <20180410154905.GE2817@twin.jikos.cz>
On 10.04.2018 18:49, David Sterba wrote:
> On Thu, Feb 22, 2018 at 06:12:13PM +0200, Nikolay Borisov wrote:
>> Currently this function handles both the READ and WRITE dio cases. This
>> is facilitated by a bunch of 'if' statements, a goto short-circuit
>> statement and a very perverse aliasing of "!created"(READ) case
>> by setting lockstart = lockend and checking for lockstart < lockend for
>> detecting the write. Let's simplify this mess by extracting the
>> READ-only code into a separate __btrfs_get_block_direct_read function.
>> This is only the first step, the next one will be to factor out the
>> write side as well. The end goal will be to have the common locking/
>> unlocking code in btrfs_get_blocks_direct and then it will call either
>> the read|write subvariants. No functional changes.
>
> Reviewed-by: David Sterba <dsterba@suse.com>
>
> uh what a convoluted code to untangle. A few style notes below.
>>
>> Signed-off-by: Nikolay Borisov <nborisov@suse.com>
>> ---
>> fs/btrfs/inode.c | 49 ++++++++++++++++++++++++++++++++++++-------------
>> 1 file changed, 36 insertions(+), 13 deletions(-)
>>
>> diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
>> index 491a7397f6fa..fd99347d0c91 100644
>> --- a/fs/btrfs/inode.c
>> +++ b/fs/btrfs/inode.c
>> @@ -7677,6 +7677,27 @@ static struct extent_map *create_io_em(struct inode *inode, u64 start, u64 len,
>> return em;
>> }
>>
>> +
>> +static int __btrfs_get_blocks_direct_read(struct extent_map *em,
>
> Please drop the "__" the function is static and there's no
> underscore-less version.
>
>> + struct buffer_head *bh_result,
>> + struct inode *inode,
>> + u64 start, u64 len)
>> +{
>> + if (em->block_start == EXTENT_MAP_HOLE ||
>> + test_bit(EXTENT_FLAG_PREALLOC, &em->flags))
>> + return -ENOENT;
>> +
>> + len = min(len, em->len - (start - em->start));
>> +
>> + bh_result->b_blocknr = (em->block_start + (start - em->start)) >>
>> + inode->i_blkbits;
>> + bh_result->b_size = len;
>> + bh_result->b_bdev = em->bdev;
>> + set_buffer_mapped(bh_result);
>> +
>> + return 0;
>> +}
>> +
>> static int btrfs_get_blocks_direct(struct inode *inode, sector_t iblock,
>> struct buffer_head *bh_result, int create)
>> {
>> @@ -7745,11 +7766,22 @@ static int btrfs_get_blocks_direct(struct inode *inode, sector_t iblock,
>> goto unlock_err;
>> }
>>
>> - /* Just a good old fashioned hole, return */
>> - if (!create && (em->block_start == EXTENT_MAP_HOLE ||
>> - test_bit(EXTENT_FLAG_PREALLOC, &em->flags))) {
>> + if (!create) {
>> + ret = __btrfs_get_blocks_direct_read(em, bh_result, inode,
>> + start, len);
>> + /* Can be negative only if we read from a hole */
>> + if (ret < 0) {
>> + ret = 0;
>> + free_extent_map(em);
>> + goto unlock_err;
>> + }
>> + /*
>> + * We need to unlock only the end area that we aren't using
>> + * if there is any leftover space
>> + */
>> + free_extent_state(cached_state);
>> free_extent_map(em);
>> - goto unlock_err;
>> + return 0;
>
> Please add a separate label for that, the funcion uses the single exit
> block style (labels and one-or-two returns).
So I think this is unnecessary because in 2/2 I factor out common code
i.e. the free_extent_map(em); return 0; outside of the 'if' branch and
so this return disappears. The 3rd hunk in 2/2 begins with:
@@ -7780,106 +7882,8 @@ static int btrfs_get_blocks_direct(struct inode
*inode, sector_t iblock,
* if there is any leftover space
*/
free_extent_state(cached_state);
- free_extent_map(em);
- return 0;
- }
>
>> }
>>
>> /*
>> @@ -7761,12 +7793,6 @@ static int btrfs_get_blocks_direct(struct inode *inode, sector_t iblock,
>> * just use the extent.
>> *
>> */
>> - if (!create) {
>> - len = min(len, em->len - (start - em->start));
>> - lockstart = start + len;
>> - goto unlock;
>> - }
>> -
>> if (test_bit(EXTENT_FLAG_PREALLOC, &em->flags) ||
>> ((BTRFS_I(inode)->flags & BTRFS_INODE_NODATACOW) &&
>> em->block_start != EXTENT_MAP_HOLE)) {
>> @@ -7853,10 +7879,7 @@ static int btrfs_get_blocks_direct(struct inode *inode, sector_t iblock,
>> clear_extent_bit(&BTRFS_I(inode)->io_tree, lockstart,
>> lockend, unlock_bits, 1, 0,
>> &cached_state);
>> - } else {
>> - free_extent_state(cached_state);
>> }
>> -
>> free_extent_map(em);
>>
>> return 0;
next prev parent reply other threads:[~2018-04-11 7:23 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-22 16:12 [PATCH 1/2] btrfs: Factor out read portion of btrfs_get_blocks_direct Nikolay Borisov
2018-02-22 16:12 ` [PATCH 2/2] btrfs: Factor out write " Nikolay Borisov
2018-04-10 16:06 ` David Sterba
2018-04-10 15:49 ` [PATCH 1/2] btrfs: Factor out read " David Sterba
2018-04-11 7:22 ` Nikolay Borisov [this message]
2018-04-19 15:53 ` David Sterba
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=e68cd719-3a3c-b125-eed0-97bf7f1afb08@suse.com \
--to=nborisov@suse.com \
--cc=dsterba@suse.cz \
--cc=linux-btrfs@vger.kernel.org \
/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).