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: <381fd674-d533-4470-88cd-b989256b44c0@intel.com>
Date: Mon, 26 Jan 2026 10:25:29 +0800
From: "Guo, Wangyang" <wangyang.guo@...el.com>
To: K Prateek Nayak <kprateek.nayak@....com>,
 Vincent Guittot <vincent.guittot@...aro.org>
Cc: Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>,
 Juri Lelli <juri.lelli@...hat.com>,
 Dietmar Eggemann <dietmar.eggemann@....com>,
 Steven Rostedt <rostedt@...dmis.org>, Ben Segall <bsegall@...gle.com>,
 Mel Gorman <mgorman@...e.de>, Valentin Schneider <vschneid@...hat.com>,
 linux-kernel@...r.kernel.org, Shrikanth Hegde <sshegde@...ux.ibm.com>,
 Benjamin Lei <benjamin.lei@...el.com>, Tim Chen
 <tim.c.chen@...ux.intel.com>, Tianyou Li <tianyou.li@...el.com>
Subject: Re: [PATCH v3] sched/clock: Avoid false sharing for
 sched_clock_irqtime

On 1/24/2026 12:48 AM, K Prateek Nayak wrote:
> Hello Vincent,
> 
> On 1/23/2026 9:28 PM, Vincent Guittot wrote:
>>> If TSC / any potentially unstable clock is marked unstable before
>>> sched_clock_init_late(), we never flip __sched_clock_stable.
>>>
>>> On x86 side, since we already start using TSC for native_sched_clock()
>>> super early, we have defensive measures (and a __use_tsc static key on
>>> the x86 side too) to switch the sched clock back to jiffies if we
>>> realise TSC was unstable before we hit sched_clock_init_late().
>>>
>>> This is necessary since post the sched_clock_init(),
>>> "sched_clock_running" is true and the local clocks will always uses
>>> sched_clock_noinstr() and it must be switch to jiffies on the x86 side
>>> since arch defines it.
>>
>> sched_clock_init_late() is always called so can't we check if
>> irqtime_enabled and clock is unstable then we disable irqtime
>> accounting
> 
> That can be done, yes.
> 
> Wangyang, can you also consolidate the irqtime disable bits (TSC and
> generic) to trigger at sched_clock_init_late() if the clock was found
> unstable and in __sched_clock_work()?
> 
> Both context can directly do a static_branch_disable() without
> needing an extra delayed work.

Thanks for the advise, v4 sent out, please help to review:
https://lore.kernel.org/all/20260126021401.1490163-1-wangyang.guo@intel.com/

BR
Wangyang

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ