[PATCH sched-next] sched/cputime: Fix unused value issue

[PATCH sched-next] sched/cputime: Fix unused value issue

[Dheeraj Reddy Jonnalagadda]

This commit fixes an unused value issue detected by Coverity
(CID 1357987). The value of utime is updated but has no use as it is
updated later on without using the stored value.

Signed-off-by: Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com>
---
 kernel/sched/cputime.c | 10 +++-------
 1 file changed, 3 insertions(+), 7 deletions(-)

diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
index 0bed0fa1acd9..3dea3636a260 100644
--- a/kernel/sched/cputime.c
+++ b/kernel/sched/cputime.c
@@ -571,13 +571,9 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
 	 * Once a task gets some ticks, the monotonicity code at 'update:'
 	 * will ensure things converge to the observed ratio.
 	 */
-	if (stime == 0) {
-		utime = rtime;
-		goto update;
-	}
-
-	if (utime == 0) {
-		stime = rtime;
+	if (stime == 0 || utime == 0) {
+		if (utime == 0)
+			stime = rtime;
 		goto update;
 	}
 
-- 
2.34.1

Re: [PATCH sched-next] sched/cputime: Fix unused value issue

[Steven Rostedt]

On Mon, 18 Nov 2024 16:43:14 +0530
Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com> wrote:

> This commit fixes an unused value issue detected by Coverity
> (CID 1357987). The value of utime is updated but has no use as it is
> updated later on without using the stored value.
> 
> Signed-off-by: Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com>
> ---
>  kernel/sched/cputime.c | 10 +++-------
>  1 file changed, 3 insertions(+), 7 deletions(-)
> 
> diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> index 0bed0fa1acd9..3dea3636a260 100644
> --- a/kernel/sched/cputime.c
> +++ b/kernel/sched/cputime.c
> @@ -571,13 +571,9 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
>  	 * Once a task gets some ticks, the monotonicity code at 'update:'
>  	 * will ensure things converge to the observed ratio.
>  	 */
> -	if (stime == 0) {
> -		utime = rtime;
> -		goto update;
> -	}
> -
> -	if (utime == 0) {
> -		stime = rtime;
> +	if (stime == 0 || utime == 0) {
> +		if (utime == 0)
> +			stime = rtime;
>  		goto update;
>  	}
>  

The above adds more branches than just having:

	if (stime == 0)
		goto update;

	if (utime == 0) {
		stime = rtime;
		goto update;
	}

(or's "||" are branches)

And the latter is much easier to read!

Just fix the issue. Don't try to be clever about it.

-- Steve

Re: [PATCH sched-next] sched/cputime: Fix unused value issue

[Peter Zijlstra]

On Mon, Nov 18, 2024 at 03:30:47PM -0500, Steven Rostedt wrote:
> On Mon, 18 Nov 2024 16:43:14 +0530
> Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com> wrote:
> 
> > This commit fixes an unused value issue detected by Coverity
> > (CID 1357987). The value of utime is updated but has no use as it is
> > updated later on without using the stored value.
> > 
> > Signed-off-by: Dheeraj Reddy Jonnalagadda <dheeraj.linuxdev@gmail.com>
> > ---
> >  kernel/sched/cputime.c | 10 +++-------
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/kernel/sched/cputime.c b/kernel/sched/cputime.c
> > index 0bed0fa1acd9..3dea3636a260 100644
> > --- a/kernel/sched/cputime.c
> > +++ b/kernel/sched/cputime.c
> > @@ -571,13 +571,9 @@ void cputime_adjust(struct task_cputime *curr, struct prev_cputime *prev,
> >  	 * Once a task gets some ticks, the monotonicity code at 'update:'
> >  	 * will ensure things converge to the observed ratio.
> >  	 */
> > -	if (stime == 0) {
> > -		utime = rtime;
> > -		goto update;
> > -	}
> > -
> > -	if (utime == 0) {
> > -		stime = rtime;
> > +	if (stime == 0 || utime == 0) {
> > +		if (utime == 0)
> > +			stime = rtime;
> >  		goto update;
> >  	}
> >  
> 
> The above adds more branches than just having:
> 
> 	if (stime == 0)
> 		goto update;
> 
> 	if (utime == 0) {
> 		stime = rtime;
> 		goto update;
> 	}
> 
> (or's "||" are branches)
> 
> And the latter is much easier to read!
> 
> Just fix the issue. Don't try to be clever about it.

There is nothing to fix. Yes there is an unused assignment, but the
compiler is free to elide it (and it does).

Keep the code as is, it is simple and straight-forward.

Re: [PATCH sched-next] sched/cputime: Fix unused value issue

[Steven Rostedt]

On Tue, 19 Nov 2024 09:36:50 +0100
Peter Zijlstra <peterz@infradead.org> wrote:

> > The above adds more branches than just having:
> > 
> > 	if (stime == 0)
> > 		goto update;
> > 
> > 	if (utime == 0) {
> > 		stime = rtime;
> > 		goto update;
> > 	}
> > 
> > (or's "||" are branches)
> > 
> > And the latter is much easier to read!
> > 
> > Just fix the issue. Don't try to be clever about it.  
> 
> There is nothing to fix. Yes there is an unused assignment, but the
> compiler is free to elide it (and it does).

This has nothing to do with the compiler optimizing it.

> 
> Keep the code as is, it is simple and straight-forward.

I disagree from a stability and understandability point of view. Why is
utime assigned? Here's the full context:

	if (stime == 0) {
		utime = rtime;  <<<---- Assigns utime
		goto update;    <<<---- Jumps to "update"
	}

	if (utime == 0) {
		stime = rtime;
		goto update;
	}

	stime = mul_u64_u64_div_u64(stime, rtime, stime + utime);
	/*
	 * Because mul_u64_u64_div_u64() can approximate on some
	 * achitectures; enforce the constraint that: a*b/(b+c) <= a.
	 */
	if (unlikely(stime > rtime))
		stime = rtime;

update:                           <<<---- Jumped here
	/*
	 * Make sure stime doesn't go backwards; this preserves monotonicity
	 * for utime because rtime is monotonic.
	 *
	 *  utime_i+1 = rtime_i+1 - stime_i
	 *            = rtime_i+1 - (rtime_i - utime_i)
	 *            = (rtime_i+1 - rtime_i) + utime_i
	 *            >= utime_i
	 */
	if (stime < prev->stime)
		stime = prev->stime;
	utime = rtime - stime;   <<<---- reassigns utime

So the first assignment of "utime" is meaningless, or there's a bug here
that utime incorrectly had its value overwritten. If the first assignment
is meaningless, it leaves others still wondering if there is actually a bug
here, because they are wondering "why was utime assigned?".

-- Steve