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]
Date:	Mon, 29 Mar 2010 18:43:18 +0900
From:	Hidetoshi Seto <seto.hidetoshi@...fujitsu.com>
To:	Andi Kleen <andi@...stfloor.org>
CC:	tglx@...utronix.de, linux-kernel@...r.kernel.org, torvalds@...l.org
Subject: Re: [PATCH] Allow Intel platforms to declare unsynchronized TSC to
 kernel

(2010/03/29 16:46), Andi Kleen wrote:
> Andi Kleen <andi@...stfloor.org> writes:
> 
>> Allow Intel platforms to declare unsynchronized TSC to kernel
>>
>> [This came out of a private discussion with Linus last week]
> 
> Ping?  Please review this patch.
> 
> -Andi

Does "constant" implicitly means "synchronized"?
IMHO the answer is no.

Following commit tells us that there could be
"constant-but-unsynchronized TSC":
 6c56ccecf05fafe100ab4ea94f6fccbf5ff00db7
> So, reenable TSC sync test even on constant and non-stop TSC systems.

Quote from the patch description of commit:
 40fb17152c50a69dc304dd632131c2f41281ce44
> Add support for CPUID_0x80000007_Bit8 on Intel CPUs as well. This bit means
> that the TSC is invariant with C/P/T states and always runs at constant
> frequency.
>
> With Intel CPUs, we have 3 classes
> * CPUs where TSC runs at constant rate and does not stop n C-states
> * CPUs where TSC runs at constant rate, but will stop in deep C-states
> * CPUs where TSC rate will vary based on P/T-states and TSC will stop in
>   deep C-states.

It looks like that "invariant" also means "constant."

I suppose your change is intended to allow newer platform to declare
"not invariant", instead of "not invariant but constant."
Humm, but how things change...?  Still newer platform cannot declare
one of 3 classes.  Which class is "never on newer platform"?
Or we need to have 4th new class? 

At least I think your patch description needs some update,
to get more comments without confusing reviewers.


Thanks,
H.Seto

--
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ