[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#762195: libc6: libpthread: hardware-assisted lock elision hazardous on x86



On Sat, Sep 20, 2014 at 12:05:54AM -0400, Carlos O'Donell wrote:
> On Fri, Sep 19, 2014 at 9:59 PM, Henrique de Moraes Holschuh
> <hmh@debian.org> wrote:
> > On Fri, 19 Sep 2014, Carlos O'Donell wrote:
> >> On Fri, Sep 19, 2014 at 6:18 PM, Henrique de Moraes Holschuh
> >> <hmh@debian.org> wrote:
> >> > On Fri, 19 Sep 2014, Henrique de Moraes Holschuh wrote:
> >> >> I can live with that, and I think I can prepare a patch if you want me to.
> >> >
> >> > Here's a minimal patch to glibc that should do it (compile tested).
> >>
> >> The GNU C Library only uses elision if built with --enable-lock-elision=yes.
> >>
> >> All you need to do is not build glibc with this flag.
> >
> > Given Jessie's expected lifetime, I'd say the blacklist is a much better
> > choice with the data currently available.
> 
> Why not ignore this, call it a hardware problem, and let users update
> the microcode if their devices are broken?

The real problem that we try to address here is not that we want to
disable TSX on these machines because it's broken. What we want to
address here is that users might upgrade the microcode from Linux
(either during boot time or later), which will cause all processes using
pthread (which also includes systemd) to die almost instantaneously.

We might want to simply use --enable-lock-elision=no as currently no CPU
support TSX (after microcode upgrade), but the problem will be there
again once TSX support is added back to new CPUs. As the problem will
have to be solved at some point, let's do it now, especially given that
I hope that TSX will be added back during the lifetime of Jessie. I 
therefore think Henrique's approach is the correct one. It also means
that we only need to blacklist TSX on machines which have a microcode
update available.

I am currently doing a test build with his patch, if everything goes
well I'll merge it in Debian. Henrique: in that case it would be nice
if you can forward this patch upstream for discussion.

Aurelien

-- 
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
aurelien@aurel32.net                 http://www.aurel32.net


Reply to: