From: "Lukas Bulwahn" <lukas.bulwahn@gmail.com>
To: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Cc: Nathan Chancellor <natechancellor@gmail.com>,
Balbir Singh <bsingharora@gmail.com>, Tom Rix <trix@redhat.com>,
Nick Desaulniers <ndesaulniers@google.com>,
clang-built-linux@googlegroups.com,
kernel-janitors@vger.kernel.org, linux-safety@lists.elisa.tech,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] taskstats: remove unneeded dead assignment
Date: Fri, 6 Nov 2020 11:47:19 +0100 (CET) [thread overview]
Message-ID: <alpine.DEB.2.21.2011061135510.20338@felia> (raw)
In-Reply-To: <alpine.DEB.2.21.2011061113270.20338@felia>
On Fri, 6 Nov 2020, Lukas Bulwahn wrote:
>
>
> On Fri, 6 Nov 2020, Nathan Chancellor wrote:
>
> > On Fri, Nov 06, 2020 at 07:22:10AM +0100, Lukas Bulwahn wrote:
> > > make clang-analyzer on x86_64 defconfig caught my attention with:
> > >
> > > kernel/taskstats.c:120:2: warning: Value stored to 'rc' is never read \
> > > [clang-analyzer-deadcode.DeadStores]
> > > rc = 0;
> > > ^
> > >
> > > Commit d94a041519f3 ("taskstats: free skb, avoid returns in
> > > send_cpu_listeners") made send_cpu_listeners() not return a value and
> > > hence, the rc variable remained only to be used within the loop where
> > > it is always assigned before read and it does not need any other
> > > initialisation.
> > >
> > > So, simply remove this unneeded dead initializing assignment.
> > >
> > > As compilers will detect this unneeded assignment and optimize this anyway,
> > > the resulting object code is identical before and after this change.
> > >
> > > No functional change. No change to object code.
> > >
> > > Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
> >
> > Question below.
> >
> > Reviewed-by: Nathan Chancellor <natechancellor@gmail.com>
> >
> > > ---
> > > applies cleanly on current master and next-20201105
> > >
> > > Balbir, please pick this minor non-urgent clean-up patch.
> > >
> > > kernel/taskstats.c | 1 -
> > > 1 file changed, 1 deletion(-)
> > >
> > > diff --git a/kernel/taskstats.c b/kernel/taskstats.c
> > > index a2802b6ff4bb..bd18a7bf5276 100644
> > > --- a/kernel/taskstats.c
> > > +++ b/kernel/taskstats.c
> > > @@ -117,7 +117,6 @@ static void send_cpu_listeners(struct sk_buff *skb,
> > >
> > > genlmsg_end(skb, reply);
> > >
> > > - rc = 0;
> > > down_read(&listeners->sem);
> > > list_for_each_entry(s, &listeners->list, list) {
> >
> > Would it be worth moving the scope of rc into the for loop, now that it
> > is only used there? Looks like it used to be used in the main function
> > scope before commit 053c095a82cf ("netlink: make nlmsg_end() and
> > genlmsg_end() void") but if this is removed, it is only used to check
> > the return of genlmsg_unicast within the list_for_each_entry loop. Not
> > sure that buys us anything but I know you have done it in patches
> > before so I thought it was worth considering.
> >
>
> I thought about moving it into the local scope, but it is a purely
> cosmetic matter. Compilers are smart enough to generate the same code no
> matter where it is defined.
> So, I always look around in the same file to determine if there is some
> kind of strong preference for very locally scoped variable definition or
> if they are generally just all defined at the function entry.
>
> Depending on my gut feeling in which style the file has mainly been
> written, I then go with the one or other option. In this case, I went
> with just keeping the definition at the function entry.
>
> There is really no strong rule, though, that I see serving as good
> indicator.
>
> Thanks for your review.
>
More specifically, if I think rc should be only defined locally, I would
probably need to apply the same argument to skb_next in this function and
put that in local scope as well. That did not happen in the past, so I am
not going to change that now neither. Hence, the change stays minimal
invasive but and that is important: it makes clang-analyzer happy.
And a happy clang-analyzer will eventually point to real bugs :)
There are a few examples of dead store warnings that in the end really
point to missing or wrong paths in some functions...
Lukas
next prev parent reply other threads:[~2020-11-06 10:47 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-11-06 6:22 [PATCH] taskstats: remove unneeded dead assignment Lukas Bulwahn
2020-11-06 9:50 ` Nathan Chancellor
2020-11-06 10:23 ` Lukas Bulwahn
2020-11-06 10:47 ` Lukas Bulwahn [this message]
2020-11-06 10:25 ` [linux-safety] " Sudip Mukherjee
2020-11-06 10:31 ` Lukas Bulwahn
2020-11-06 12:04 ` Sudip Mukherjee
2020-11-06 12:38 ` Lukas Bulwahn
2020-11-10 8:06 ` Dan Carpenter
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=alpine.DEB.2.21.2011061135510.20338@felia \
--to=lukas.bulwahn@gmail.com \
--cc=bsingharora@gmail.com \
--cc=clang-built-linux@googlegroups.com \
--cc=kernel-janitors@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-safety@lists.elisa.tech \
--cc=natechancellor@gmail.com \
--cc=ndesaulniers@google.com \
--cc=trix@redhat.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