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

Message-ID: <zo3detrsg6pajav5pf5mtfup6ivmqkcz62canmcpdaogwxje7i@maojpum2cfd7>
Date: Sat, 18 Jan 2025 16:37:00 +0900
From: Koichiro Den <koichiro.den@...onical.com>
To: Thomas Gleixner <tglx@...utronix.de>
Cc: linux-kernel@...r.kernel.org, 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:24:07AM GMT, Thomas Gleixner wrote:
> 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.
> 

Thank you for the feedback and handling it.

-Koichiro Den