linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: zhong jiang <zhongjiang@huawei.com>
Cc: clm@fb.com, jbacik@fb.com, dsterba@suse.com,
	linux-btrfs@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] fs/btrfs: remove the unneeded variable "err" and change the function to be void function
Date: Tue, 7 Aug 2018 17:25:00 +0200	[thread overview]
Message-ID: <20180807152500.GJ3218@twin.jikos.cz> (raw)
In-Reply-To: <1533523978-50321-1-git-send-email-zhongjiang@huawei.com>

On Mon, Aug 06, 2018 at 10:52:58AM +0800, zhong jiang wrote:
> The err is not modified after initalization, So just remove it and make
> the function to be void function.
> 
> Signed-off-by: zhong jiang <zhongjiang@huawei.com>
> ---
> v1->v2:
>  - Merge v1 series into a patch to void same changelog.

Please do one patch per function. If the change follows the same logic,
it's not a problem to use the same changelog, but the patch should be
revieweable and not doing unrelated things.

If the function prototype or return values is changed it's easier from
the reviewer's perspective to focus on just one function and the
surrounding code. Even if it looks straightforward to you to merge them
together.

When the return value changes from int -> void, it's necessary to check
wheter any of the callees is not hiding a BUG_ON that should be really
turned into proper error handling in the caller. In that case the return
type should stay and error handling added.

After a brief look I think all functions are safe here, but that's
something that should be mentioned in the changelog. Please update the
patches and resend. Thanks.

  reply	other threads:[~2018-08-07 15:25 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-08-06  2:52 [PATCH v2] fs/btrfs: remove the unneeded variable "err" and change the function to be void function zhong jiang
2018-08-07 15:25 ` David Sterba [this message]
2018-08-08 14:11   ` zhong jiang

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=20180807152500.GJ3218@twin.jikos.cz \
    --to=dsterba@suse.cz \
    --cc=clm@fb.com \
    --cc=dsterba@suse.com \
    --cc=jbacik@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=zhongjiang@huawei.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;
as well as URLs for NNTP newsgroup(s).