linux-kernel - Re: [PATCH v2] sched/cputime: Resync steal time when guest & host lose sync

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CANRm+CyUi+4b8bk10Hc+eV+Xm8ahvoYNNAp_ScH7Lp4gD=iDJQ@mail.gmail.com>
Date:	Wed, 17 Aug 2016 10:05:34 +0800
From:	Wanpeng Li <kernellwp@...il.com>
To:	Rik van Riel <riel@...hat.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	kvm <kvm@...r.kernel.org>, Wanpeng Li <wanpeng.li@...mail.com>,
	Ingo Molnar <mingo@...nel.org>,
	Peter Zijlstra <peterz@...radead.org>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Radim Krcmar <rkrcmar@...hat.com>,
	Mike Galbraith <efault@....de>,
	Frederic Weisbecker <fweisbec@...il.com>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH v2] sched/cputime: Resync steal time when guest & host
 lose sync

2016-08-17 9:54 GMT+08:00 Rik van Riel <riel@...hat.com>:
> On Wed, 2016-08-17 at 09:16 +0800, Wanpeng Li wrote:
>>
>> @@ -694,6 +699,12 @@ static cputime_t get_vtime_delta(struct
>> task_struct *tsk)
>>       unsigned long now = READ_ONCE(jiffies);
>>       cputime_t delta, other;
>>
>> +     /*
>> +      * The interval returned by account_other_time() is NOT
>> +      * rounded down to the nearest jiffy, while the base
>> +      * interval it is subtracted from is. So the max cputime
>> +      * limit is required to avoid underflow.
>> +      */
>>       delta = jiffies_to_cputime(now - tsk->vtime_snap);
>>       other = account_other_time(delta);
>>       WARN_ON_ONCE(tsk->vtime_snap_whence == VTIME_INACTIVE);
>
> That comment makes sense in the context of the discussion
> we have been having over the past few days, but could be
> somewhat cryptic to someone looking at it 3 years from now.
>
> How about something like the following?
>
>         /*
>          * Unlike tick based timing, vtime based timing never has lost
>          * ticks, and no need for steal time accounting to make up for
>          * lost ticks. Vtime accounts a rounded version of actual
>          * elapsed time. Limit account_other_time to prevent rounding
>          * errors from causing elapsed vtime to go negative.
>          */

Great, thanks for your help. I will send out a new version soon. :)

Regards,
Wanpeng Li