Am 29.09.2014 um 15:14 schrieb Carlos O'Donell:
On 09/28/2014 02:17 PM, Reindl Harald wrote:
>> What about the case where the user runs a custom kernel?
> then he needs to build it right
That's not sufficiently conservative for a core runtime.
from the viewpoint of a distribution in context of the kernel?
well, try to write a kernel bugreport if you are using
a custom built one on the RH bugzilla....
> don't get me wrong but you can't seriously disable TSX
> completly because a *possible* out-of-distribution kernel
I am not disabling TSX completely. I am disabling the use of
TSX in POSIX threads (particularly rwlocks and default mutex
locks)
in context of the issue of the topic you need to disable
it completly without early mircocode loading because
the whole CPU capability is gone after it is applied
I would also not disable it forever, I would disable
it until we have more discussion and consensus around the
best solution.
agreed - that's what i liked to hear confirmed to not
have it disabled in 2 years because there maybe old
and affected hardware "in the wild"
At the present moment I'm reluctant to commit to hardware
blacklists in glibc, but this might be one way forward.
Alternately we forgo the use of cpuid and rely on the kernel
to always tell us which features are present and useful
* how do you do that?
* from where is cpuid coming - IMHO it's from the kernel (/proc/cpuinfo)
the issue is the time where microcode get updated due boot
to not break already loaded code if a capability is gone like
TSX after that