[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1463555429.16365.43.camel@redhat.com>
Date: Wed, 18 May 2016 03:10:29 -0400
From: Rik van Riel <riel@...hat.com>
To: Wanpeng Li <kernellwp@...il.com>, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org
Cc: Wanpeng Li <wanpeng.li@...mail.com>,
Ingo Molnar <mingo@...nel.org>,
"Peter Zijlstra (Intel)" <peterz@...radead.org>,
Thomas Gleixner <tglx@...utronix.de>,
Frederic Weisbecker <fweisbec@...il.com>,
Paolo Bonzini <pbonzini@...hat.com>, Radim <rkrcmar@...hat.com>
Subject: Re: [PATCH] sched/cputime: add steal time support to full dynticks
CPU time accounting
On Tue, 2016-05-10 at 13:34 +0800, Wanpeng Li wrote:
>
> +++ b/kernel/sched/cputime.c
>
> @@ -691,8 +691,11 @@ static cputime_t get_vtime_delta(struct
> task_struct *tsk)
>
> static void __vtime_account_system(struct task_struct *tsk)
> {
> + unsigned long steal_time = steal_account_process_tick();
> cputime_t delta_cpu = get_vtime_delta(tsk);
>
> + delta_cpu = steal_time ? (delta_cpu -
> + jiffies_to_cputime(steal_time)) : delta_cpu;
> account_system_time(tsk, irq_count(), delta_cpu,
> cputime_to_scaled(delta_cpu));
> }
>
Sorry to have to go back on my previous email, but
this is now a NAK
The above code can end up passing a negative number
to account_system_time(), which in turn can cause a
divide by zero in scale_stime()
The code needs to ensure that if all the time that
passed was accounted as steal time (which could be
more jiffies than expected, due to remaining partial
jiffies in steal_account_process_tick), the function
does not call account_system_time().
--
All Rights Reversed.
Download attachment "signature.asc" of type "application/pgp-signature" (474 bytes)
Powered by blists - more mailing lists