linux-kernel - Re: question about logic of steal_account_process

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: <56D9F45C.5050602@windriver.com>
Date:	Fri, 4 Mar 2016 14:47:24 -0600
From:	Chris Friesen <chris.friesen@...driver.com>
To:	lkml <linux-kernel@...r.kernel.org>,
	Frederic Weisbecker <fweisbec@...il.com>
Subject: Re: question about logic of steal_account_process_tick() ?

On 03/04/2016 01:51 PM, Chris Friesen wrote:

> The thing is, steal_account_process_tick() returns units of cputime, which I
> think is nanoseconds on x86_64.  So if we have a tiny amount of stolen time it
> seems like that will prevent a whole tick from being accounted into
> user/system/idle.
>
> I feel like I must be missing something here, can someone tell me what it is?

Looking at commit dee08a72 (from 2014) it seems like the units of the return 
value of steal_account_process_tick() changed from ticks to cputime_t.  I don't 
see an equivalent change in the logic in account_process_tick(), which seems to 
assume that a nonzero return value in steal_account_process_tick() means a whole 
tick has been stolen.

Was there a change to make paravirt_steal_clock() increment in ticks?  If not it 
seems like there's a unit mismatch here.

Chris