mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: Zheng Yejian <zhengyejian1@huawei.com>
Cc: <mingo@redhat.com>, <linux-kernel@vger.kernel.org>,
	<tom.zanussi@linux.intel.com>, <trix@redhat.com>,
	<stable@vger.kernel.org>, <zhangjinhao2@huawei.com>
Subject: Re: [PATCH] tracing/histograms: Simplify create_hist_fields()
Date: Tue, 12 Jul 2022 13:49:56 -0400	[thread overview]
Message-ID: <20220712134956.4acb90a3@gandalf.local.home> (raw)
In-Reply-To: <20220630013152.164871-1-zhengyejian1@huawei.com>

On Thu, 30 Jun 2022 09:31:52 +0800
Zheng Yejian <zhengyejian1@huawei.com> wrote:

> When I look into implements of create_hist_fields(), I think there can be
> following two simplifications:
>   1. If something wrong happened in parse_var_defs(), free_var_defs() would
>      have been called in it, so no need goto free again after calling it;
>   2. After calling create_key_fields(), regardless of the value of 'ret', it
>      then always runs into 'out: ', so the judge of 'ret' is redundant.
> 
> No functional changes.

I applied this but removed the "No functional changes" because it is a
functional change. The end result may be the same, but the flow is
different, and that means it changed functionally.

The only time "No functional changes" should be stated is if you move code
around or change #ifdefs to perform the same action. IOW, if the assembly
produced by the compiler is the same before and after your change, you can
say "No functional changes", otherwise don't ever say that.

This is important, because if a bisect lands on this, people may think the
bisect is incorrect, when in reality it could be the cause of the bug (I
just had this happen to me with another commit that had "No functional
changes" :-p )

-- Steve


> 
> Signed-off-by: Zheng Yejian <zhengyejian1@huawei.com>

  parent reply	other threads:[~2022-07-12 17:50 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-30  1:31 Zheng Yejian
2022-06-30  2:24 ` Tom Rix
2022-06-30  6:33 ` Greg KH
2022-06-30  9:21   ` Zhengyejian (Zetta)
2022-07-12 17:49 ` Steven Rostedt [this message]
2022-07-13 10:32   ` Zheng Yejian
2022-07-12 17:52 ` Steven Rostedt

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=20220712134956.4acb90a3@gandalf.local.home \
    --to=rostedt@goodmis.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@redhat.com \
    --cc=stable@vger.kernel.org \
    --cc=tom.zanussi@linux.intel.com \
    --cc=trix@redhat.com \
    --cc=zhangjinhao2@huawei.com \
    --cc=zhengyejian1@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

all inboxes | Powered by JetHome®