linux-kernel - Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on CPUs like i7-4910MQ : bug #194609

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: <alpine.DEB.2.20.1702220958590.3782@nanos>
Date:   Wed, 22 Feb 2017 11:53:33 -0800 (PST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Jason Vas Dias <jason.vas.dias@...il.com>
cc:     kernel-janitors@...r.kernel.org,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        Prarit Bhargava <prarit@...hat.com>, x86@...nel.org
Subject: Re: [PATCH] arch/x86/kernel/tsc.c : set X86_FEATURE_ART for TSC on
 CPUs like i7-4910MQ : bug #194609

On Wed, 22 Feb 2017, Jason Vas Dias wrote:

> Yes, my CPU is still getting a fault every time the TSC_ADJUST MSR is
> read or written . It is probably because it genuinuely does not support
> any cpuid > 13 , or the modern TSC_ADJUST interface.

Err no. TSC_ADJUST is available when CPUID(70 EBX has bit 1 set.

Please provide the output of:

# cpuid -1 -r

for that machine

> This is probably why my clock_gettime() latencies are so bad. Now I have
> to develop a patch to disable all access to TSC_ADJUST MSR if
> boot_cpu_data.cpuid_level <= 13 .  I really have an unlucky CPU :-) .

Can you just try to boot linux 4.10 on that machine an report whether it
works? It will touch the TSC_ADJUST MRS when the feature bit is set.

> But really, I think this issue goes deeper into the fundamental limits of
> time measurement on Linux : it is never going to be possible to measure
> minimum times with clock_gettime() comparable with those returned by
> rdtscp instruction - the time taken to enter the kernel through the VDSO,
> queue an access to vsyscall_gtod_data via a workqueue, access it & do
> computations & copy value to user-space

Sorry, that's not how the VDSO works. It does not involve workqueues, copy
to user space and whatever. VDSO is mapped into user space and only goes
into the when TSC is not working or the VDSO access is disabled or you want
to access a CLOCKID which is not supported in the VDSO.

> is NEVER going to be up to the job of measuring small real-time durations
> of the order of 10-20 TSC ticks .

clock_gettime(CLOCK_MONOTONIC) via VDSO takes ~20ns on my haswell laptop

> I think the best way to solve this problem going forward would be to store
> the entire vsyscall_gtod_data  data structure representing the current
> clocksource
> in a shared page which is memory-mappable (read-only) by user-space .

This is what VDSO does. It provides the data R/O to user space and it also
provides the accessor functions.

CLOCK_MONOTONIC, CLOCK_REALTIME, CLOCK_MONOTONIC_COARSE and
CLOCK_REALTIME_COARSE are handled in the VDSO (user space) and never enter
the kernel.

I really have a hard time to understand what you are trying to solve.

Thanks,

	tglx