From: Sidong Yang <realwakka@gmail.com>
To: Filipe Manana <fdmanana@gmail.com>
Cc: linux-btrfs <linux-btrfs@vger.kernel.org>,
David Sterba <dsterba@suse.cz>,
Nikolay Borisov <nborisov@suse.com>
Subject: Re: [PATCH v2] btrfs: reflink: Initialize return value in btrfs_extent_same()
Date: Mon, 23 Aug 2021 23:51:34 +0000 [thread overview]
Message-ID: <20210823235134.GA45534@realwakka> (raw)
In-Reply-To: <CAL3q7H5UvRXk7TLQOt-bnkN4Tca-v7c6JBW6vz90KEaYJuMp1g@mail.gmail.com>
On Mon, Aug 23, 2021 at 10:44:08AM +0100, Filipe Manana wrote:
> On Fri, Aug 20, 2021 at 1:42 AM Sidong Yang <realwakka@gmail.com> wrote:
> >
> > btrfs_extent_same() cannot be called with zero length. This patch add
> > code that initialize ret as -EINVAL to make it safe.
>
> I suppose the motivation of the patch is to fix a warning from smatch,
> or other similar tools, about 'ret' not being initialized when olen is
> 0.
Yes, Actually I used smatch you said.
> Initializing 'ret' to some value surely makes the warning go away,
> even though it's not possible for olen to be 0 at btrfs_extent_same(),
> as that
> is filtered up in the call chain.
>
> However setting to -EINVAL by default is confusing and counter
> intuitive because dedupe operations are supposed to return 0 (success)
> for a 0 length range.
Yeah, I think it depends on btrfs_extent_same()'s concept. It does
nothing when 0 length. It's okay if we consider it's normal operation
and it seems natural.
>
> So 'ret' should be initialized to 0 to avoid any confusion.
Agree. I want to know other people's thoughts.
Thanks,
Sidong
> Thanks.
>
> >
> > Signed-off-by: Sidong Yang <realwakka@gmail.com>
> > ---
> > v2:
> > - Removed assert and added initializing ret
> > ---
> > fs/btrfs/reflink.c | 1 +
> > 1 file changed, 1 insertion(+)
> >
> > diff --git a/fs/btrfs/reflink.c b/fs/btrfs/reflink.c
> > index 9b0814318e72..864f42198c5c 100644
> > --- a/fs/btrfs/reflink.c
> > +++ b/fs/btrfs/reflink.c
> > @@ -653,6 +653,7 @@ static int btrfs_extent_same(struct inode *src, u64 loff, u64 olen,
> > u64 i, tail_len, chunk_count;
> > struct btrfs_root *root_dst = BTRFS_I(dst)->root;
> >
> > + ret = -EINVAL;
> > spin_lock(&root_dst->root_item_lock);
> > if (root_dst->send_in_progress) {
> > btrfs_warn_rl(root_dst->fs_info,
> > --
> > 2.25.1
> >
>
>
> --
> Filipe David Manana,
>
> “Whether you think you can, or you think you can't — you're right.”
next prev parent reply other threads:[~2021-08-23 23:52 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-20 0:41 [PATCH v2] btrfs: reflink: Initialize return value in btrfs_extent_same() Sidong Yang
2021-08-20 6:08 ` Nikolay Borisov
2021-08-20 11:17 ` David Sterba
2021-08-20 11:50 ` Sidong Yang
2021-08-23 9:44 ` Filipe Manana
2021-08-23 23:51 ` Sidong Yang [this message]
2021-08-26 14:08 ` 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=20210823235134.GA45534@realwakka \
--to=realwakka@gmail.com \
--cc=dsterba@suse.cz \
--cc=fdmanana@gmail.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=nborisov@suse.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.