linux-kernel - Re: [PATCH RFC] tick/nohz: fix data races in get_cpu_idle_time

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: <Y9lzCaC2k/Un64O3@hirez.programming.kicks-ass.net>
Date:   Tue, 31 Jan 2023 20:59:05 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Alexey Dobriyan <adobriyan@...il.com>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Yu Liao <liaoyu15@...wei.com>, fweisbec@...il.com,
        mingo@...nel.org, liwei391@...wei.com,
        mirsad.todorovac@....unizg.hr, linux-kernel@...r.kernel.org
Subject: Re: [PATCH RFC] tick/nohz: fix data races in get_cpu_idle_time_us()

On Tue, Jan 31, 2023 at 09:35:39PM +0300, Alexey Dobriyan wrote:

> > Seriously this procfs accuracy is the least of the problems and if this
> > would be the only issue then we could trivially fix it by declaring that
> > the procfs output might go backwards.
> 
> Declarations on l-k are meaningless.

Not really, we often do the -EWONTFIX thing.

> > If there would be a real reason to ensure monotonicity there then we could
> > easily do that in the readout code.
> 
> People expect it to be monotonic. I wrote this test fully expecting
> that /proc/uptime is monotonic. It didn't ever occured to me that
> idletime can go backwards (nor uptime, but uptime is not buggy).

People want ponies too -- people will just have to cope with not having
ponies.