linux-kernel - Re: [PATCH] hrtimer: reset .hres_active and .online at appropriate points

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: <875xmfaz7s.ffs@tglx>
Date: Thu, 16 Jan 2025 10:24:07 +0100
From: Thomas Gleixner <tglx@...utronix.de>
To: Koichiro Den <koichiro.den@...onical.com>, linux-kernel@...r.kernel.org
Cc: anna-maria@...utronix.de, frederic@...nel.org, peterz@...radead.org
Subject: Re: [PATCH] hrtimer: reset .hres_active and .online at appropriate
 points

On Thu, Jan 16 2025 at 10:16, Thomas Gleixner wrote:

> On Fri, Dec 20 2024 at 22:44, Koichiro Den wrote:
>> Reset these fields at the appropriate points. Ideally, .hres_active
>> would be reset in tick_cpu_dying() as underlying clockevent is shut down
>> there. However, since these operations occur in the atomic AP section
>> with interrupts disabled in any case, this patch resets .hres_active to
>> 0 in hrtimers_cpu_dying() for simplicity.
>
> It does not matter where it is reset and from a hrtimer point of view
> the dying() callback is the appropriate place.

That said. The change is actually incomplete as the other fields which
are related to the per CPU base state are not reset either.