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

WARNING: multiple messages have this Message-ID (diff)
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, 06 Nov 2020 10:47:19 +0000	[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

  reply	other threads:[~2020-11-06 10:47 UTC|newest]

Thread overview: 22+ 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  6:22 ` Lukas Bulwahn
2020-11-06  9:50 ` Nathan Chancellor
2020-11-06  9:50   ` Nathan Chancellor
2020-11-06 10:23   ` Lukas Bulwahn
2020-11-06 10:23     ` Lukas Bulwahn
2020-11-06 10:23     ` Lukas Bulwahn
2020-11-06 10:47     ` Lukas Bulwahn [this message]
2020-11-06 10:47       ` Lukas Bulwahn
2020-11-06 10:47       ` Lukas Bulwahn
2020-11-06 10:25 ` [linux-safety] " Sudip Mukherjee
2020-11-06 10:25   ` Sudip Mukherjee
2020-11-06 10:31   ` Lukas Bulwahn
2020-11-06 10:31     ` Lukas Bulwahn
2020-11-06 10:31     ` Lukas Bulwahn
2020-11-06 12:04     ` Sudip Mukherjee
2020-11-06 12:04       ` Sudip Mukherjee
2020-11-06 12:38       ` Lukas Bulwahn
2020-11-06 12:38         ` Lukas Bulwahn
2020-11-06 12:38         ` Lukas Bulwahn
2020-11-10  8:06       ` Dan Carpenter
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 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.