linux-kernel - Re: [RFC] cputime: Introduce option to force full dynticks accounting on NOHZ & NOHZ

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZdTQyb23KJEYqbcw@google.com>
Date: Tue, 20 Feb 2024 08:18:17 -0800
From: Sean Christopherson <seanjc@...gle.com>
To: Nicolas Saenz Julienne <nsaenz@...zon.com>
Cc: frederic@...nel.org, paulmck@...nel.org, jalliste@...zon.co.uk, 
	mhiramat@...nel.org, akpm@...ux-foundation.org, pmladek@...e.com, 
	rdunlap@...radead.org, tsi@...oix.net, nphamcs@...il.com, 
	gregkh@...uxfoundation.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org, 
	pbonzini@...hat.com
Subject: Re: [RFC] cputime: Introduce option to force full dynticks accounting
 on NOHZ & NOHZ_IDLE CPUs

On Mon, Feb 19, 2024, Nicolas Saenz Julienne wrote:
> Under certain extreme conditions, the tick-based cputime accounting may
> produce inaccurate data. For instance, guest CPU usage is sensitive to
> interrupts firing right before the tick's expiration. This forces the
> guest into kernel context, and has that time slice wrongly accounted as
> system time. This issue is exacerbated if the interrupt source is in
> sync with the tick, significantly skewing usage metrics towards system
> time.

..

> NOTE: This wasn't tested in depth, and it's mostly intended to highlight
> the issue we're trying to solve. Also ccing KVM folks, since it's
> relevant to guest CPU usage accounting.

How bad is the synchronization issue on upstream kernels?  We tried to address
that in commit 160457140187 ("KVM: x86: Defer vtime accounting 'til after IRQ handling").

I don't expect it to be foolproof, but it'd be good to know if there's a blatant
flaw and/or easily closed hole.