linux-kernel - Re: [PATCH] x86: Fix call to set_cyc2ns_scale() from time_cpufreq

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]

Date:	Mon, 07 Apr 2008 14:33:51 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Karsten Wiese <fzu@...gehoertderstaat.de>
Cc:	linux-kernel@...r.kernel.org, Ingo Molnar <mingo@...e.hu>,
	Thomas Gleixner <tglx@...utronix.de>
Subject: Re: [PATCH] x86: Fix call to set_cyc2ns_scale() from time_cpufreq_notifier()

Karsten Wiese <fzu@...gehoertderstaat.de> writes:

> In time_cpufreq_notifier() the cpu id to act upon is held in freq->cpu. Use it
> instead of smp_processor_id() in the call to set_cyc2ns_scale().
> This makes the preempt_*able() unnecessary and lets set_cyc2ns_scale() update
> the intended cpu's cyc2ns.

It is still wrong because set_cyc2ns_scale() needs to execute on the target CPU
because it does rdtsc on that CPU. If you're on another CPU you'll
get the wrong values if the TSCs are not synchronized.

Still wrong as just disabling preemption around the call is not correct,
it would need to cover the complete notifier event and also the cpufreq
code would need to guarantee it is always already running on the correct
CPU (not sure that is the case currently)

The whole thing needs to be either preempt disabled or the RDTSC update code
needs to be moved into a smp_call_function_simple()  [my old 
"redesigned sched_clock code" did that]

Using smp_call_function_simple() would be probably the right fix,
perhaps conditional on a check for unsync TSC.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/