All of lore.kernel.org
 help / color / mirror / Atom feed
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.”

  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.