sched/cputime: Remove unnecessary assignment statement
diff mbox series

Message ID 1551248002-27303-1-git-send-email-ketanp@nvidia.com
State Deferred
Headers show
Series
  • sched/cputime: Remove unnecessary assignment statement
Related show

Commit Message

Ketan Patil Feb. 27, 2019, 6:13 a.m. UTC
The original code assigns the value from rtime to utime variable,
and then jumps to the update label. And the value of utime is then
updated, so the earlier value of utime is not used. Hence remove
that unnecessary assignment statement.

This fixes one of the coverity defects.

Based on work by Ishan Mittal <imittal@nvidia.com>

Signed-off-by: Ketan Patil <ketanp@nvidia.com>
---
 kernel/sched/cputime.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

Comments

Peter Zijlstra Feb. 27, 2019, 10:32 a.m. UTC | #1
On Wed, Feb 27, 2019 at 11:43:22AM +0530, Ketan Patil wrote:
> The original code assigns the value from rtime to utime variable,
> and then jumps to the update label. And the value of utime is then
> updated, so the earlier value of utime is not used. Hence remove
> that unnecessary assignment statement.
> 
> This fixes one of the coverity defects.

Why does coverity care? I like the way the code is now, it makes
conceptual sense. Removing that assignment makes the code harder to read
and less symmetric (see the utime case right below).

Any sensible compiler will 'fix' this for us anyway.

> Based on work by Ishan Mittal <imittal@nvidia.com>
> Signed-off-by: Ketan Patil <ketanp@nvidia.com>
> ---
>  kernel/sched/cputime.c | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
> 
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index ba4a143..ad64771 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -616,10 +616,8 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
>  	 * Once a task gets some ticks, the monotonicy code at 'update:'
>  	 * will ensure things converge to the observed ratio.
>  	 */
> -	if (stime == 0) {
> -		utime = rtime;
> +	if (stime == 0)
>  		goto update;
> -	}
>  
>  	if (utime == 0) {
>  		stime = rtime;
Ketan Patil Feb. 28, 2019, 9:42 a.m. UTC | #2
The coverity tool has detected this issue as an unused value, since

the code assigns the value to utime variable and then after the jump, the

value of utime again gets updated, hence the previous value is not at all

useful and this patch removes that first assignment.

On 27/02/19 4:02 PM, Peter Zijlstra wrote:
> On Wed, Feb 27, 2019 at 11:43:22AM +0530, Ketan Patil wrote:
>> The original code assigns the value from rtime to utime variable,
>> and then jumps to the update label. And the value of utime is then
>> updated, so the earlier value of utime is not used. Hence remove
>> that unnecessary assignment statement.
>>
>> This fixes one of the coverity defects.
> Why does coverity care? I like the way the code is now, it makes
> conceptual sense. Removing that assignment makes the code harder to read
> and less symmetric (see the utime case right below).
>
> Any sensible compiler will 'fix' this for us anyway.
>
>> Based on work by Ishan Mittal <imittal@nvidia.com>
>> Signed-off-by: Ketan Patil <ketanp@nvidia.com>
>> ---
>>   kernel/sched/cputime.c | 4 +---
>>   1 file changed, 1 insertion(+), 3 deletions(-)
>>
>> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
>> index ba4a143..ad64771 100644
>> --- a/kernel/sched/cputime.c
>> +++ b/kernel/sched/cputime.c
>> @@ -616,10 +616,8 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
>>   	 * Once a task gets some ticks, the monotonicy code at 'update:'
>>   	 * will ensure things converge to the observed ratio.
>>   	 */
>> -	if (stime == 0) {
>> -		utime = rtime;
>> +	if (stime == 0)
>>   		goto update;
>> -	}
>>   
>>   	if (utime == 0) {
>>   		stime = rtime;
Peter Zijlstra Feb. 28, 2019, 9:47 a.m. UTC | #3
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

On Thu, Feb 28, 2019 at 03:12:13PM +0530, Ketan Patil wrote:
> The coverity tool has detected this issue as an unused value, since
> the code assigns the value to utime variable and then after the jump, the
> value of utime again gets updated, hence the previous value is not at all
> useful and this patch removes that first assignment.

Not a security issue then; just tell coverity to shut up.
Sachin Nikam Feb. 28, 2019, 12:14 p.m. UTC | #4
Ketan,
What is the Coverity Impact Level for this defect?
If it is Low then we can whitelist this defect and change.

Peter,
This isn't a security fix.
However, I see this is kind of code cleanup.

-----Original Message-----
From: Peter Zijlstra <peterz@infradead.org> 
Sent: Thursday, February 28, 2019 3:18 PM
To: Ketan Patil <ketanp@nvidia.com>
Cc: mingo@redhat.com; linux-kernel@vger.kernel.org; linux-tegra@vger.kernel.org; Sachin Nikam <Snikam@nvidia.com>; Bharat Nihalani <bnihalani@nvidia.com>; Bo Yan <byan@nvidia.com>; Sai Gurrappadi <sgurrappadi@nvidia.com>; Thierry Reding <treding@nvidia.com>; Timo Alho <talho@nvidia.com>
Subject: Re: [PATCH] sched/cputime: Remove unnecessary assignment statement


A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

On Thu, Feb 28, 2019 at 03:12:13PM +0530, Ketan Patil wrote:
> The coverity tool has detected this issue as an unused value, since 
> the code assigns the value to utime variable and then after the jump, 
> the value of utime again gets updated, hence the previous value is not 
> at all useful and this patch removes that first assignment.

Not a security issue then; just tell coverity to shut up.
Peter Zijlstra Feb. 28, 2019, 12:31 p.m. UTC | #5
Clearly, because reading comprehension isn't your strong point:

A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing in e-mail?

On Thu, Feb 28, 2019 at 12:14:09PM +0000, Sachin Nikam wrote:

> This isn't a security fix.
> However, I see this is kind of code cleanup.

As I've explained previously, it makes conceptual sense to have it in
the code, and any halfway sane compiler will observe the same double
store and eliminate it in its DCE pass.
Jon Hunter Feb. 28, 2019, 1:53 p.m. UTC | #6
On 28/02/2019 12:31, Peter Zijlstra wrote:
> 
> Clearly, because reading comprehension isn't your strong point:
> 
> A: Because it messes up the order in which people normally read text.
> Q: Why is top-posting such a bad thing?
> A: Top-posting.
> Q: What is the most annoying thing in e-mail?

Sorry we have a few people helping out cleaning up our kernel branches
and we need to do a better job here indeed!

> On Thu, Feb 28, 2019 at 12:14:09PM +0000, Sachin Nikam wrote:
> 
>> This isn't a security fix.
>> However, I see this is kind of code cleanup.
> 
> As I've explained previously, it makes conceptual sense to have it in
> the code, and any halfway sane compiler will observe the same double
> store and eliminate it in its DCE pass.

OK. Thanks for the feedback. We can agree to drop this and we will try
to do a better job reviewing this type of thing before hand in future.

Cheers
Jon

Patch
diff mbox series

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index ba4a143..ad64771 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -616,10 +616,8 @@  void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
 	 * Once a task gets some ticks, the monotonicy code at 'update:'
 	 * will ensure things converge to the observed ratio.
 	 */
-	if (stime == 0) {
-		utime = rtime;
+	if (stime == 0)
 		goto update;
-	}
 
 	if (utime == 0) {
 		stime = rtime;