Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86
On Thu, 16 Oct 2014, Carlos O'Donell wrote:
> I disagree. IMO the most flexible approach is for glibc to stop using cpuid
> for RTM detection and rely on the kernel to tell it if RTM is usable. Then
> we have a single hardware blacklist in the kernel. We need to talk to
> kernel people about this. Not to mention we might extend a getauxval-type
> API to prevent applications from using cpuid directly e.g. create a
> platform header for this with an x86 specific feature interface.
We are about to freeze for the Jessie release. I am only asking that we put
a stopgap measure in place until a proper fix can be deployed upstream (and
backported to Debian's glibc 2.19 and Linux 3.16).
At this time I don't care whether we go with the processor blacklist or take
the more conservative path and disable lock elision code in Debian, as long
as we do something.
*I* can't do much more than provide patches, I am not about to NMU glibc.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: