Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86
On Mon, Oct 20, 2014 at 11:51:14AM -0200, Henrique de Moraes Holschuh wrote:
> 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).
This is a serious issue, and there is a bug report about it. We will
definitely fix it before the release. The freeze is only one step and not
an excuse to rush things. An RC bug can be fixed after the freeze, even
if it would be better to fix it before.
In addition I have been busy with things that are I consider more
important, fixing glibc and tzdata for old-stable and stable.
> 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 feel sad that the lock elision code can't really be disabled without
using additional patches that are not even upstream. I have tested your
blacklist patch, and it works fine on the few systems I have tested.
I'll therefore go that way.
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@aurel32.net http://www.aurel32.net
Reply to: