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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
