Debian Bug report logs - #800574
libc6: lock elision hazard on Intel Broadwell and Skylake

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: libc6: lock elision hazard on Intel Broadwell and Skylake

Date: Thu, 1 Oct 2015 00:17:19 -0300

Package: libc6
Version: 2.19-4
Severity: grave
Justification: causes non-serious data loss

Intel Broadwell-H and Skylake-S/H have critical errata that causes HLE
to be extremely dangerous to use on those processors, resulting in
unpredictable behavior (i.e. process crashes when you are lucky, data
corruption when you are not) when hardware lock-elision is enabled in
glibc/libpthread.

Broadwell errata BBD50 (desktop/mobile), BDW50 (server):

	An HLE (Hardware Lock Elision) transactional region begins with
	an instruction with the XACQUIRE prefix.  Due to this erratum,
	reads from within the transactional region of the memory
	destination of that instruction may return the value that was
	in memory before the transactional region began

According to the Intel errata list, a firmware fix is possible, but I
have no idea whether it is done by toggling a boot-locked MSR that
disables HLE, or through a microcode update.  The MSR is more likely,
but if it is a microcode update, it is going to be as much of a hazard
as the Haswell one that disabled TSX+HLE.

I recommend that we extend the HLE blacklist in glibc to also include
CPU signature 0x40671.  This will disable HLE on Xeon E3-1200v4, and
5th-generation Core i5/i7.  These processors are supposed to already
have TSX disabled (errata BBD51/BDW51).

Skylake's latest public specification update still doesn't list any HLE
errata, but it is not really recent.  OTOH, there is a Gentoo user's
report that Skylake is also unstable when HLE is enabled in glibc and
that the crashes stop when glibc is compiled without lock elision.

For that reason, it might be a good idea to also blacklist HLE on CPU
signatures 0x506e1, 0x506e2 and 0x506e3, which would disable HLE on
Skylake-S and Skylake-H (6th gen Core i5/i7).  This won't cover the
Skylake Xeon E3-1200v5, for which there are no reports of breakage (nor
a public specification update I could find).

References: 
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=762195
https://bbs.archlinux.org/viewtopic.php?id=202545

In hindsight, it looks like we would have been better off by disabling
lock elision entirely for Debian jessie when we fixed #762195.
Something to consider when the time comes to fix this bug in stable
through a stable update...

-- 
  "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

Message #10 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: 800574@bugs.debian.org

Subject: More details and references

Date: Thu, 01 Oct 2015 07:50:15 -0300

According to this thread in the kernel bugzilla:
https://bugzilla.kernel.org/show_bug.cgi?id=103351

We have a fix for the HLE BDW50 errata confirmed for Broadwell-H,
through updated microcode.

Broadwell-H errata BDW50 fix:
signature 0x40671, pf_mask 0x22, revision >= 0x12

Which would allow us to selectively blacklist only Broadwell with
"outdated" microcode.  I can (and will) make a major ruckus about this
set of Broadwell and Skylake microcode updates when it becomes pratical
to distribute them in Debian, but due to the non-free nature of Intel
microcode updates, that will fix things for a small fraction of our
users, so we blacklisting in glibc anyway. Same deal as Haswell :-(

There is also a Skylake microcode update available (dated 2015-08-08), I
can prepare an experimental intel-microcode package with all such
updates if anyone would be so kind as to test it, so that we can get
independent reports of the HLE situation in Skylake.

-- 
  "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 de Moraes Holschuh <hmh@debian.org>

Message #15 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: 800574@bugs.debian.org

Subject: Re: More details and references

Date: Sun, 4 Oct 2015 15:37:39 -0300

On Thu, 01 Oct 2015, Henrique de Moraes Holschuh wrote:
> We have a fix for the HLE BDW50 errata confirmed for Broadwell-H,
> through updated microcode.
> 
> Broadwell-H errata BDW50 fix:
> signature 0x40671, pf_mask 0x22, revision >= 0x12
> 
> Which would allow us to selectively blacklist only Broadwell with
> "outdated" microcode.  I can (and will) make a major ruckus about this

...

> There is also a Skylake microcode update available (dated 2015-08-08), I

Which has been confirmed to fix the HLE issue there, as well.

Further datapoints: other than the E7-v3 Xeons, it looks like HLE is
critically broken on anything running microcode older than 2015-04.  We can
probably depend on Broadwell-DE (Xeon D-1500) motherboards to ship with
new-enough microcode.

My search was not completely exhaustive and I don't have priviledged access
to any Intel documentation, so I might have missed a processor family or
two, etc.

Still, I could not find *anything* supposed to support TSX/HLE that didn't
have either the old Haswell "TSX may cause unpredictable system behavior"
erratum, or the newer errata "TSX not available" and "reading the memory
destination of an instruction that begins an HLE transaction may return the
original value" listed.  Skylake's spec update doesn't list them yet as of
2015-10-04, but we *know* it has either the same or very similar errata, and
that it got fixed by a recent microcode update.


So, for non-free and Ubuntu, microcode updates through the intel-microcode
package are likely to be a viable way to fix this: it all depends on the
required microcode updates being made available in the first place.

But non-free is not Debian, people rarely update their firmware unless you
push hard for it, and it takes at least six months for fixed microcode to be
reasonably available through firmware updates.

Just ignoring the issue (read: passively documenting it), while still an
option, should be left as the least desireable choice IMO.


Unfortunately, blacklisting HLE by microcode revision would require parsing
/proc/cpuinfo ATM, which is not really desireable for the HLE blacklist
code, to put it lightly.  So, it looks like any blacklisting done in the
library code will have to be all-or-nothing: fixing the processor by a
microcode update will not lift the blacklist.

Also, processors that share the same CPU signature have to blacklisted as a
group, even if they take different microcode (which would also be a problem
for microcode-revision-based whitelists: we *might* need to know the
processor's microcode platform flags in some cases).

I recommend that, for Debian stable (jessie), we switch to a whitelist-based
approach for HLE support, currently only whitelisting the latest stepping of
Haswell-EX (Xeon E7-v3) and Broadwell-DE (Xeon D-1500).  We can revisit that
decision in six months or one year, and possibly switch back to blacklisting
instead of whitelisting.

Only processors that are known to never have been widely deployed with HLE
errata would be eligible to be whitelisted.

This means at least Broadwell, Broadwell-H, and Skylake-H/S would never get
HLE support reenabled in Debian jessie, which includes several Xeon
processors.  Obviously, if we ever find a way to make the blacklist
microcode-revision aware, we can do better.

For unstable, we could adopt the same whitelisting approach in the short
term (three to six months), while we work on something more flexible that
would allow processors that got a later-than-launch errata fix to get
delisted from the HLE "whitelist-based blacklist".


One should keep in mind that, if we add such blacklisting, we also need to
decide how we will deal with removals from the blacklist in the future due
to fixed microcode being made available: should we lift the blacklisting for
a processor signature, it will regress systems still missing the microcode
update (fixable by installing non-free intel-microcode and rebooting before
upgrading glibc).

It is possible to add preinst logic to abort glibc install/upgrades for the
"we are removing this processor signature from the blackist, and
/proc/cpuinfo lists a microcode revision known to be broken" case.  This
takes care of regressions (in a rather user-unfriendly way, though) should
we decide that users ought to either install firmware updates, or tolerate
installing non-free intel-microcode.   Something would need to be done for
the Debian installer as well (to address new installs).


I really wish we had without-HLE and with-HLE variants of glibc for x86-64,
with non-HLE being the preferred/default choice for now (the preferred
choice being something to revisit in the future, as working HLE becomes more
widespread).

Then, we could have as-complex-as-required blacklisting logic in the preinst
of the HLE variant, which could be easily be made microcode-revision aware,
etc.  It would be really user-unfriendly when tripped (refuse the install /
abort the upgrade), but at least it would be safer.


Comments?

-- 
  "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

Message #20 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: 800574@bugs.debian.org

Subject: Final analysis for Broadwell

Date: Wed, 07 Oct 2015 07:32:33 -0300

Well, I've finally finished analysing things for Broadwell.

The amd64 (x86-64) glibc lock elision code keys on the RTM CPUID bit
because it is actually using RTM (and not HLE) to implement lock
elision.  I failed to keep this in mind when worrying about permanently
blacklisting Broadwell processors from glibc lock elision in unstable.

Errata BDM53/BDW51/BDD51/BDE42 "Intel TSX Instructions not avalilable"
_should_ mean that trying to use any of the TSX-NI opcodes (i.e. RTM) in
Broadwell would always result in an illegal opcode exception (SIGILL). 
The specificaton updates also explicitly say in the descriptions of
these errata that the RTM bit in CPUID is not set.

Were those errata present on every microcode revision/core versions of
those processors, it would make them "safe" as far as our (patched)
glibc lock elision is concerned.  We are not that lucky.

Seaching the network for cpuinfo reports resulted in a /proc/cpuinfo
dump of signature 0x306d4, microcode rev 0x11 (Core i5-5300U), and rev
0x18 (Core M-5Y71), where both RTM and HLE are reported as enabled.

Another /proc/cpuinfo dump of signature 0x306d4, with microcode rev 0x18
(Core i5-5300U and also Core M-5Y10c) and rev 0x1f (Core i5-5287U),
shows both HLE and RTM already disabled.

The fact that revision 0x18 had a different CPUID response for (Core
i5-5300U, Core M-5Y10c), and Core M-5Y71 was a surprise.
Perhaps it also has a dependency on the firmware doing a (hopefully
boot-locked) wrmsr to disable TSX.

Anyway, regardless of the reason, one cannot count on the RTM and HLE
bits being disabled in CPUID(7) on every Broadwell processor and
microcode revision out there.

OTOH, it does means we can, and should, blacklist signature 0x306d4 (and
earlier) permanently, because RTM is extremely unlikely to be
fixed/fixable on these processors. Either it is disabled as it should be
per the errata documentation, or enabled and very dangerous (resulting
in either SIGILL or Haswell-style risk of unpredictable system
behavior).  Since signature 0x40671 also has the same "TSX unavailable"
type of errata (BDD51, BDE42), I guess we can assume the same applies to
Broadwell-H and Broadwell-DE, and blacklist lock elision there
permanently as well.

I am still collecting data for Skylake-S, but it boils down to whether
up-to-date Skylake-S microcode (revisions 0x34 and higher) fixes, or
disable TSX.  We know that microcode update does stop glibc lock elision
crashing with SIGSEGV, though.


Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did
provide for a possible long-term plan to fine-tune the lock-elision
blacklist (and anything else of that sort).

We would have to (finally) extend x86-64 hwcap to cpuid(1) fully, and
also at least cpuid(7), which is anything but trivial and a lot of work.
 This is _not_ worth the trouble if it is done just for lock elision
blacklisting purposes.

However, it would be useful for link-time optimization in libraries
(e.g. avx2 flavours of something that really benefits from it, etc), so
it is likely worth pursuing... but only if we get buy-in from upstream.

Once it is there for far better purposes than blacklisting, there is no
reason not to do the trivial work to have the kernel blacklist whatever
capabilities should be avoided, and switch glibc to use the hwcap
extension instead of doing cpuid directly wherever available, thus
making it usable _also_ for blacklisting things.

-- 
  "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 de Moraes Holschuh <hmh@debian.org>

Message #25 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: 800574@bugs.debian.org

Subject: Re: Final analysis for Broadwell

Date: Thu, 08 Oct 2015 22:20:47 -0300

[Message part 1 (text/plain, inline)]

tag 800574 + patch
thanks

Attached updated version of amd64/local-blacklist-on-TSX-Haswell.diff.  
I believe it should be renamed to
"amd64/local-blacklist-for-Intel-TSX.diff" as it is not just about Intel
Haswell anymore.

The updated patch has been package-compile-tested on glibc 2.19-22.

This new version of the blacklist patch had the patch header text and
blacklist code comments updated.   It doesn't change anything for
Haswell.  It adds to the blacklist the current Broadwell CPU models and
steppings.

Broadwell-H with a very recent microcode update (rev 0x12, from
2015-06-04) was confirmed to have broken TSX-NI (RTM) and to _leave it
enabled_ in CPUID, causing glibc with lock elision enabled to SIGSEGV. 
An even more recent Broadwell-H microcode update, rev 0x13 from
2015-08-03, is confirmed to (finally) disable the HLE and RTM CPUID
bits.  This should make blacklisting signature 0x40671 uncontroversial.

Refer to https://bugzilla.kernel.org/show_bug.cgi?id=103351 for details.

This version of the blacklist patch leaves upcoming Broadwell-E
unblacklisted.  It also leaves Skylake unblacklisted, as I have not been
able to confirm whether the newest Skylake-S microcode updates have
working Intel TSX-NI, or have it disabled.

I propose that the updated blacklist patch be added to glibc in
unstable, and after it spends a few weeks in testing, that it should
also be the added to stable through a stable update.

-- 
  "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 de Moraes Holschuh <hmh@debian.org>

[local-blacklist-for-Intel-TSX.diff (text/x-diff, attachment)]

Message #32 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Henrique de Moraes Holschuh <hmh@debian.org>, 800574@bugs.debian.org

Subject: Re: Bug#800574: Final analysis for Broadwell

Date: Sun, 18 Oct 2015 21:57:30 +0200

On 2015-10-08 22:20, Henrique de Moraes Holschuh wrote:
> tag 800574 + patch
> thanks
> 
> Attached updated version of amd64/local-blacklist-on-TSX-Haswell.diff.  
> I believe it should be renamed to
> "amd64/local-blacklist-for-Intel-TSX.diff" as it is not just about Intel
> Haswell anymore.
> 
> The updated patch has been package-compile-tested on glibc 2.19-22.
> 
> This new version of the blacklist patch had the patch header text and
> blacklist code comments updated.   It doesn't change anything for
> Haswell.  It adds to the blacklist the current Broadwell CPU models and
> steppings.
> 
> Broadwell-H with a very recent microcode update (rev 0x12, from
> 2015-06-04) was confirmed to have broken TSX-NI (RTM) and to _leave it
> enabled_ in CPUID, causing glibc with lock elision enabled to SIGSEGV. 
> An even more recent Broadwell-H microcode update, rev 0x13 from
> 2015-08-03, is confirmed to (finally) disable the HLE and RTM CPUID
> bits.  This should make blacklisting signature 0x40671 uncontroversial.
> 
> Refer to https://bugzilla.kernel.org/show_bug.cgi?id=103351 for details.
> 
> This version of the blacklist patch leaves upcoming Broadwell-E
> unblacklisted.  It also leaves Skylake unblacklisted, as I have not been
> able to confirm whether the newest Skylake-S microcode updates have
> working Intel TSX-NI, or have it disabled.
> 
> I propose that the updated blacklist patch be added to glibc in
> unstable, and after it spends a few weeks in testing, that it should
> also be the added to stable through a stable update.

Thanks for the patch, I have committed it to the jessie and the 2.21
branches.

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

Message #37 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Henrique de Moraes Holschuh <hmh@debian.org>, 800574@bugs.debian.org

Subject: Re: Bug#800574: Final analysis for Broadwell

Date: Sun, 18 Oct 2015 22:15:33 +0200

On 2015-10-07 07:32, Henrique de Moraes Holschuh wrote:
> Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did
> provide for a possible long-term plan to fine-tune the lock-elision
> blacklist (and anything else of that sort).
> 
> We would have to (finally) extend x86-64 hwcap to cpuid(1) fully, and
> also at least cpuid(7), which is anything but trivial and a lot of work.
>  This is _not_ worth the trouble if it is done just for lock elision
> blacklisting purposes.
> 
> However, it would be useful for link-time optimization in libraries
> (e.g. avx2 flavours of something that really benefits from it, etc), so
> it is likely worth pursuing... but only if we get buy-in from upstream.

Why do you believe that hwcap is better for handling that than the
current STT_GNU_IFUNC mechanism?

For me hwcap is clearly superseded by the STT_GNU_IFUNC:

1) With the hwcap mechanism the libraries need to be recompiled multiple
times, increasing build time, but also the disk space on the users
computer.

2) It makes the upgrades more complex (see the nohwcap part of the libc
preinst/postinst).

3) We need to ensure the ABI is the same for all versions of the same
library (this is not the case for upstream glibc between i586 and i686).

4) The fact that the CPU supports a feature doesn't mean it supports it
with good performances. For instance Intel Silvermont supports SSE4.2,
but SSE2/SSSE3 based version of string functions are much faster there.

5) Finally it means that we need to provide a version of the libc for
all combinations. Think on i386, we would need to provide:
 - libc6
 - libc6-i686
 - libc6-i686-tsx
 - libc6-xen
 - libc6-xen-tsx

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

Message #42 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Aurelien Jarno <aurelien@aurel32.net>

Cc: 800574@bugs.debian.org

Subject: Re: Bug#800574: Final analysis for Broadwell

Date: Sun, 18 Oct 2015 21:05:19 -0200

On Sun, 18 Oct 2015, Aurelien Jarno wrote:
> > Broadwell-H with a very recent microcode update (rev 0x12, from
> > 2015-06-04) was confirmed to have broken TSX-NI (RTM) and to _leave it
> > enabled_ in CPUID, causing glibc with lock elision enabled to SIGSEGV. 
> > An even more recent Broadwell-H microcode update, rev 0x13 from
> > 2015-08-03, is confirmed to (finally) disable the HLE and RTM CPUID
> > bits.  This should make blacklisting signature 0x40671 uncontroversial.

FWIW, in the last few days it became clear that so far, the mobile
Broadwell-H disables Intel TSX, but no instances of the desktop
Broadwell-H with RTM disabled were found yet, not even with the latest
microcode.  And they all use the same microcode.

It has also became clear a few days ago that it is very likely that the
BIOS can disable Intel TSX-NI (RTM) and HLE, and it doesn't need very
recent microcode to do that either.  If this is true, it should be
something like MSR 0x13c (bit 1 of that MSR disables AES-NI when set,
and bit 0 locks that MSR against writting when set).  Maybe the Intel
TSX-NI (HLE and RTM) disable switches are even on this very same MSR...

I've also since became aware of Debian bug #750792, and it describes the
same SIGSEGV observed by Broadwell and Skylake Arch-linux users on
lock-elision-enabled glibc.  From that bug report, it is clear that the
SIGSEGVs in __lll_unlock_elision can easily happen due to software bugs,
so it need not be linked to any Intel-TSX processor errata.  And this
kind of defect is quite common, apparently.

However, since Intel's current public specification update states (as
errata) that Intel TSX-NI is not supposed to be usable in the Broadwell
and Broadwell-H cores, that it should not even be reported in CPUID by
these processors (but it is :p), and that this is not supposed to be
fixable or worked around, I still think we need to blacklist it.

I will keep tracking this issue, and report back any relevant
information that becomes available.  It would be _really_ nice if the
Intel team that works with Canonical were to shed a light on this,
though.

> Thanks for the patch, I have committed it to the jessie and the 2.21
> branches.

Thank you.

-- 
  "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

Message #47 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Aurelien Jarno <aurelien@aurel32.net>

Cc: 800574@bugs.debian.org

Subject: Re: Bug#800574: Final analysis for Broadwell

Date: Sun, 18 Oct 2015 22:15:27 -0200

On Sun, 18 Oct 2015, Aurelien Jarno wrote:
> On 2015-10-07 07:32, Henrique de Moraes Holschuh wrote:
> > Meanwhile, a suggestion by Samuel Thibault to try to use hwcap did
> > provide for a possible long-term plan to fine-tune the lock-elision
> > blacklist (and anything else of that sort).
> > 
> > We would have to (finally) extend x86-64 hwcap to cpuid(1) fully, and
> > also at least cpuid(7), which is anything but trivial and a lot of work.
> >  This is _not_ worth the trouble if it is done just for lock elision
> > blacklisting purposes.
> > 
> > However, it would be useful for link-time optimization in libraries
> > (e.g. avx2 flavours of something that really benefits from it, etc), so
> > it is likely worth pursuing... but only if we get buy-in from upstream.
> 
> Why do you believe that hwcap is better for handling that than the
> current STT_GNU_IFUNC mechanism?

I was not aware of STT_GNU_IFUNC.  I will look into it.

> 5) Finally it means that we need to provide a version of the libc for
> all combinations. Think on i386, we would need to provide:
>  - libc6
>  - libc6-i686
>  - libc6-i686-tsx
>  - libc6-xen
>  - libc6-xen-tsx

No.  We need nothing of the sort for Intel TSX.  TSX-NI is something
already detected at runtime by glibc using the cpuid instruction, there
is no need to use the dynamic loader's hwcap object selection for this.

What I proposed was to extend the kernel-supplied hwcap area for x86-64
(and x32, I suppose) to export the full flags information returned by
CPUID.EAX=1, and also by CPUID.EAX=7 to all processes... and use _that_
instead of a direct call to the cpuid instruction to detect Intel TSX
(and anything else based on cpuid(1) and cpuid(7) in glibc).

We could do it for 32-bit too, I suppose.  But if hardware-assisted lock
elision is important enough to justify that kind of work for i686, that
just means we should deploy x32 instead, as far as I'm concerned.

Then, change glibc to use this extended hwcap information to detect such
runtime-selected features instead of calling the cpuid instruction
directly on the processor.  On an older kernel without the extended
hwcap fields, either call cpuid directly, or disable them.

However, for stuff like AVX512, you might want to have the *entire*
library compiled with a much more advanced instruction set (based on the
fact that AVX512 being available also implies that very fast SSE4.2 is
available, for example).  It would be possible to use the dynamic
linker's hwcap support to do that, if one wanted to.

-- 
  "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

Message #52 received at 800574-close@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurel32@debian.org>

To: 800574-close@bugs.debian.org

Subject: Bug#800574: fixed in glibc 2.21-0experimental2

Date: Mon, 19 Oct 2015 05:19:14 +0000

Source: glibc
Source-Version: 2.21-0experimental2

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 800574@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aurelien Jarno <aurel32@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 19 Oct 2015 00:20:34 +0200
Source: glibc
Binary: libc-bin libc-dev-bin libc-l10n glibc-doc glibc-source locales locales-all nscd multiarch-support libc6 libc6-dev libc6-dbg libc6-pic libc6-udeb libc6.1 libc6.1-dev libc6.1-dbg libc6.1-pic libc6.1-udeb libc0.3 libc0.3-dev libc0.3-dbg libc0.3-pic libc0.3-udeb libc0.1 libc0.1-dev libc0.1-dbg libc0.1-pic libc0.1-udeb libc6-i386 libc6-dev-i386 libc6-sparc libc6-dev-sparc libc6-sparc64 libc6-dev-sparc64 libc6-s390 libc6-dev-s390 libc6-amd64 libc6-dev-amd64 libc6-powerpc libc6-dev-powerpc libc6-ppc64 libc6-dev-ppc64 libc6-mips32 libc6-dev-mips32 libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386 libc0.1-dev-i386 libc6-x32 libc6-dev-x32 libc6-i686 libc6-xen libc0.1-i686 libc0.3-i686 libc0.3-xen libc6.1-alphaev67 libnss-dns-udeb libnss-files-udeb
Architecture: source
Version: 2.21-0experimental2
Distribution: experimental
Urgency: medium
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Changed-By: Aurelien Jarno <aurel32@debian.org>
Description:
 glibc-doc  - GNU C Library: Documentation
 glibc-source - GNU C Library: sources
 libc-bin   - GNU C Library: Binaries
 libc-dev-bin - GNU C Library: Development binaries
 libc-l10n  - GNU C Library: localization files
 libc0.1    - GNU C Library: Shared libraries
 libc0.1-dbg - GNU C Library: detached debugging symbols
 libc0.1-dev - GNU C Library: Development Libraries and Header Files
 libc0.1-dev-i386 - GNU C Library: 32bit development libraries for AMD64
 libc0.1-i386 - GNU C Library: 32bit shared libraries for AMD64
 libc0.1-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.1-pic - GNU C Library: PIC archive library
 libc0.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3    - GNU C Library: Shared libraries
 libc0.3-dbg - GNU C Library: detached debugging symbols
 libc0.3-dev - GNU C Library: Development Libraries and Header Files
 libc0.3-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.3-pic - GNU C Library: PIC archive library
 libc0.3-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3-xen - GNU C Library: Shared libraries [Xen version]
 libc6      - GNU C Library: Shared libraries
 libc6-amd64 - GNU C Library: 64bit Shared libraries for AMD64
 libc6-dbg  - GNU C Library: detached debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files
 libc6-dev-amd64 - GNU C Library: 64bit Development Libraries for AMD64
 libc6-dev-i386 - GNU C Library: 32-bit development libraries for AMD64
 libc6-dev-mips32 - GNU C Library: o32 Development Libraries for MIPS
 libc6-dev-mips64 - GNU C Library: 64bit Development Libraries for MIPS64
 libc6-dev-mipsn32 - GNU C Library: n32 Development Libraries for MIPS64
 libc6-dev-powerpc - GNU C Library: 32bit powerpc development libraries for ppc64
 libc6-dev-ppc64 - GNU C Library: 64bit Development Libraries for PowerPC64
 libc6-dev-s390 - GNU C Library: 32bit Development Libraries for IBM zSeries
 libc6-dev-sparc - GNU C Library: 32bit Development Libraries for SPARC
 libc6-dev-sparc64 - GNU C Library: 64bit Development Libraries for UltraSPARC
 libc6-dev-x32 - GNU C Library: X32 ABI Development Libraries for AMD64
 libc6-i386 - GNU C Library: 32-bit shared libraries for AMD64
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-mips32 - GNU C Library: o32 Shared libraries for MIPS
 libc6-mips64 - GNU C Library: 64bit Shared libraries for MIPS64
 libc6-mipsn32 - GNU C Library: n32 Shared libraries for MIPS64
 libc6-pic  - GNU C Library: PIC archive library
 libc6-powerpc - GNU C Library: 32bit powerpc shared libraries for ppc64
 libc6-ppc64 - GNU C Library: 64bit Shared libraries for PowerPC64
 libc6-s390 - GNU C Library: 32bit Shared libraries for IBM zSeries
 libc6-sparc - GNU C Library: 32bit Shared libraries for SPARC
 libc6-sparc64 - GNU C Library: 64bit Shared libraries for UltraSPARC
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc6-x32  - GNU C Library: X32 ABI Shared libraries for AMD64
 libc6-xen  - GNU C Library: Shared libraries [Xen version]
 libc6.1    - GNU C Library: Shared libraries
 libc6.1-alphaev67 - GNU C Library: Shared libraries (EV67 optimized)
 libc6.1-dbg - GNU C Library: detached debugging symbols
 libc6.1-dev - GNU C Library: Development Libraries and Header Files
 libc6.1-pic - GNU C Library: PIC archive library
 libc6.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales    - GNU C Library: National Language (locale) data [support]
 locales-all - GNU C Library: Precompiled locale data
 multiarch-support - Transitional package to ensure multiarch compatibility
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 672774 764692 785796 788799 797538 797831 798064 798316 799418 800574 800846 801691 802256
Changes:
 glibc (2.21-0experimental2) experimental; urgency=medium
 .
   [ Samuel Thibault ]
   * Symbol versions which contain _DEBIAN_ are unexpected by upstream scripts.
     Add hurd-i386-only patches/hurd-i386/local-versions-hack.diff to work
     around the issue.  Also take the opportunity of the upstream version bump
     to bump the versions to GLIBC_2_21, which will allow one to remove the
     _DEBIAN_ hacks once packages are rebuilt.
   * patches/hurd-i386/unsubmitted-libpthread-semaphore.h.diff: Remove
     libpthread/sysdeps/i386/bits/semaphore.h, now that hurd Implies
     libpthread/sysdeps/generic. Move libpthread/include/semaphore.h into
     libpthread/sysdeps/pthread/semaphore.h instead of the latter just
     including the former, since the latter is what gets installed.
   * patches/hurd-i386/cvs-cache-mach_host_self.diff: New patch to avoid port
     count issue on the host port.
   * patches/hurd-i386/unsubmitted-gnumach.defs.diff: Also build
     task_notify.defs stubs.  Drop unneeded change.
   * libc0.3.symbols.hurd-i386: Update.
   * patches/hurd-i386/local-mach_print.diff: New patch to export mach_print.
 .
   [ Aurelien Jarno ]
   * rules.d/debhelper.mk: replace GLIBC_VERSION before LIBC.  Closes:
     #797538.
   * Drop loongson-2f flavour on mipsel as this machine is not supported
     anymore (default to R2 ISA).
   * kfreebsd/local-sysdeps.diff: update to revision 5772 (from glibc-bsd).
     Closes: #764692, #785796.
   * testsuite-checking/expected-results-mips*: allow the new tst-audit9
     fail, like the others tst-auditX.
   * testsuite-checking/expected-results-mips(el)-linux-gnu-libc: allow
     conformtest for sys/stat.h to fail for O32 ABI. They were previously
     under the failing test run-conformtest.out, but it has been lost in
     the conversion to the new format.
   * testsuite-checking/expected-results-mips*: sort the files. Remove
     failures due to old kernel now that all buildds run jessie.
   * debhelper.in/locales-all.prerm: do not specify a path to check for
     locale-gen.
   * libc6.1.symbols.alpha: remove invoke_dynamic_linker from libpcprofile.so.
     It has disappeared, but it is a private library.
   * Remove debver2localesdep.pl, it is unused since 2.19-16.
   * Use $(GLIBC_VERSION) for shlib, instead of defining the version in a
     separate shlibver file.
   * Remove completely outdated README, README.source and TODO files.
   * rules.d/debhelper.mk: use the default compression format for libc6,
     libc-bin and multiarch-support. Nowadays deboostrap is able to handle
     the xz format and modern distributions also support it. Anyway almost
     all packages installed by debootstrap are now using the xz format.
   * Bump debhelper compatibility to level 9. This brings compressed debug
     file using the build-id instead of a fixed path. This is much more
     multiarch friendly.
   * control.in/*: remove pre-squeeze conflicts.
   * libc-bin, libc-dev-bin: Recommends the manpages package and add lintian
     override for missing manpages.
   * sysdeps/s390x.mk: --enable-lock-elision.
   * testsuite-checking/expected-results-x86_64-linux-gnux32-*: allow
     conformtest for headers with tv_nsec to fail for x32. The type
     non-compliance is intentional. These tests were previously marked as
     failing under the run-conformtest.out, but they have been lost during
     the conversion to the new format.
   * testsuite-checking/compare.sh: re-enable failures in case of regressions.
   * rules.d/build.mk: don't require flavours to be tested before being
     installed. They are still tested when calling the build-arch or
     binary-arch targets, but not anymore when calling the build-indep or
     binary-indep targets.
   * patches/hppa/cvs-alloca-werror.diff: new patch from upstream to fix a
     build failure.
   * debhelper.in/libc.preinst: fix up error message for too old Linux
     kernels.  Closes: #800846.
   * patches/any/cvs-ld_pointer_guard.diff: new patch from upstream to
     unconditionally disable LD_POINTER_GUARD.  Closes: #798316, #801691.
   * patches/any/cvs-mangle-tls_dtor_list.diff: new patch from upstream to
     mangle function pointers in tls_dtor_list.  Closes: #802256.
   * Update Brazilian Portuguese debconf translation, by Adriano Rafael
     Gomes.  Closes: #799418.
 .
   [ Steven Chamberlain ]
   * sysdeps/kfreebsd.mk: find kfreebsd-kernel-headers in multiarch path.
     Closes: #672774, #798064.
 .
   [ Helmut Grohne ]
   * Fix some issues with stage 1.  Closes: #797831.
 .
   [ Adam Conrad ]
   * debian/patches/arm/local-arm-futex.diff: Lie about the minimum kernel
     support for futex_atomic_cmpxchg_inatomic to restore the  previous state
     and fix the pulsesink (and others) regression on ARM (closes: #788799)
 .
   [ Henrique de Moraes Holschuh ]
   * Replace patches/amd64/local-blacklist-on-TSX-Haswell.diff by
     local-blacklist-for-Intel-TSX.diff also blacklisting some Broadwell
     models.  Closes: #800574.
Checksums-Sha1:
 fd761ec4eac7bf3d13369eab55e538574f0e2245 8248 glibc_2.21-0experimental2.dsc
 31c082c59310c4b7735bbb6717e74a4fb603f7ed 986484 glibc_2.21-0experimental2.debian.tar.xz
Checksums-Sha256:
 9fdadce8edf4dc52a5341a4306f1e1d9db2c03e5eeeb5c6512833074965f326f 8248 glibc_2.21-0experimental2.dsc
 2582ce18e1f909e9234ba3169fc2130e8a3b6324988122003647fb05e25bb7b7 986484 glibc_2.21-0experimental2.debian.tar.xz
Files:
 cba9eeba0df44a6eacecb9c6f946a7dc 8248 libs required glibc_2.21-0experimental2.dsc
 472c7e0d0fe1269e1aa94ce9c5141c3d 986484 libs required glibc_2.21-0experimental2.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWJHmqAAoJELqceAYd3YybLU4P/ArJFWaiJKc4PDSLWppEGjJj
bVooDTNIEiQ2hEyhf0cAV7elwlqLdRYlQL7L40zVt43C0IgIfKVRfAgq2OtPoCW6
78nfS2Wx39cc+LXPsGFZrARGPdw+bc/QOUOzUcQs/A39+BFuesqTl+DU0/bGpHTp
d2xOhGTWu4JNsGYK9DExlm8KvbnXEikd6xJJCmvCKbVep5YF2bXcseSdgKmZlXAw
BAFLhA/T3OblvSCoOkkZSkp/SJyMaR/KJ9LZ9Fqvt04gO2Z0ok2AdpOBMCdkMt34
vU0ACY3L1cb4+xeXDAuSvcHMi0X32m/caG/0xm3iK1rQ32erk59XhUaJy+GNXWMu
wOqoySQ8mCVZ9Zs4GsE+1M2RYCmsmumjRnV4rZAE52WF3hY+iPkodZNSDi9vh5WB
VjYh3A9G+eClAhLNM0xBV7ztmULd5koT6raTdFaWZew1In4xxn+OlhVIDWdELSOU
M86qZCNDJQpxbs0HoDgTBYLoqy4weqnY+mTejjo8EGFKXHNrK1kZ7gLQmogmTkvr
P/xI8ng7iv7odEjjsGgIVx8w8FV7V27VBQtQsSKVqogS30mJRZQ/wYsyDmWD/wne
vQ98Y0ruTGrnvTDtTxn6EVKJxq7DD4udrdt6FXuTzK+mbD+EpLfj7BgOwvIVRbxs
mgivdzwe6BsWafTtBRPu
=O16T
-----END PGP SIGNATURE-----

Message #57 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>

To: 800574@bugs.debian.org

Cc: Henrique de Moraes Holschuh <hmh@debian.org>

Subject: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)

Date: Fri, 23 Oct 2015 15:13:46 +0200

[Message part 1 (text/plain, inline)]

Hi,

Thanks for this patch.

I was having trouble (crashes with the NVIDIA proprietary driver) on a
Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable)

I tried first to update the Intel microcode with the "unreleased" 0x13
microcode version but it didn't disabled the TSX-NI instructions [1]
neither the crashes.

Finally I upgraded to glibc=2.21-0experimental2 and it fixed the crashes.

I wonder:

Should this patch be backported both to stable and unstable?


Thanks for your awesome work !


Regards
-------

[1] https://bugzilla.kernel.org/show_bug.cgi?id=103351#c93

[signature.asc (application/pgp-signature, attachment)]

Message #62 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Henrique de Moraes Holschuh <hmh@debian.org>

To: Carlos Alberto Lopez Perez <clopez@igalia.com>, 800574@bugs.debian.org

Subject: Re: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)

Date: Fri, 23 Oct 2015 18:10:47 -0200

On Fri, Oct 23, 2015, at 11:13, Carlos Alberto Lopez Perez wrote:
> I was having trouble (crashes with the NVIDIA proprietary driver) on a
> Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable)

This is very very likely to be braindamage on the NVIDIA driver, though.

Are you sure that driver is not doing something as idiotic as unlocking
an already unlocked mutex ?

The proper fix in that case is _always_ to fix whatever is broken,
because eventually it will run on something that has working hardware
lock elision... and crash.

> I tried first to update the Intel microcode with the "unreleased" 0x13
> microcode version but it didn't disabled the TSX-NI instructions [1]
> neither the crashes.

Mobile Broadwell-H seems to disable TSX, while Desktop Broadwell-H
doesn't.  That's why we blacklisted the whole thing: inconsistent
behavior on the same microcode, and that behavior is itself inconsistent
with the errata sheet that says such processors shouldn't even be able
to advertise Intel TSX RTM in CPUID.

At the moment, we don't even know what is wrong with RTM in
Broadwell/Broadwel-H/Broadwell-DE.  We do know some of what is wrong
with HLE in Broadwell/-H/-DE (and it is really nasty), but HLE is not
used by glibc in the first place, and the HLE erratum is supposedly
worked around somehow (because it is documented to be so on the Xeon
D-1500/Broadwell-DE) by the batch of microcode updates available in the
kernel bugzilla bug report mentioned in this bug report.

Broadwell-H Microcode 0x13 is useful anyway because it fixes other
critical errata that hangs/oopses the kernel: you box should be a _lot_
more stable with it.  And at least one person reported that not all
hangs were fixed by microcode 0x12, thus you probably should use keep
using microcode 0x13 (or newer, should one become available).

> Finally I upgraded to glibc=2.21-0experimental2 and it fixed the crashes.

"Works around" a bug in the NVIDIA drivers is just as likely, see above.

If we instrumented non-lock-elision glibc to complain about operations
that are illegal on most processors implementing lock elision, we'd know
for sure.

> Should this patch be backported both to stable and unstable?

It needs to go to stable sooner than later, yes.  But it seems wise to
let it cook in unstable/testing for a bit, first.

I don't know what the plans for uploading new glibc to unstable are.

-- 
  "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 de Moraes Holschuh <hmh@debian.org>

Message #67 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Henrique de Moraes Holschuh <hmh@debian.org>, 800574@bugs.debian.org

Cc: Carlos Alberto Lopez Perez <clopez@igalia.com>

Subject: Re: Bug#800574: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)

Date: Sat, 24 Oct 2015 01:44:40 +0200

On 2015-10-23 18:10, Henrique de Moraes Holschuh wrote:
> On Fri, Oct 23, 2015, at 11:13, Carlos Alberto Lopez Perez wrote:
>
> > Should this patch be backported both to stable and unstable?
> 
> It needs to go to stable sooner than later, yes.  But it seems wise to
> let it cook in unstable/testing for a bit, first.

The patch is already committed to our stable branch:

http://anonscm.debian.org/viewvc/pkg-glibc?view=revision&revision=6644

The plan is to upload it to stable-proposed-updates once we have more
fixes in (mostly the nscd bugs) or we are getting close to the next
point release.

> I don't know what the plans for uploading new glibc to unstable are.

The plan is to get glibc 2.21 to unstable soon.

Aurelien

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

Message #72 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>

To: Henrique de Moraes Holschuh <hmh@debian.org>, 800574@bugs.debian.org

Subject: Re: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)

Date: Mon, 26 Oct 2015 20:13:08 +0100

[Message part 1 (text/plain, inline)]

On 23/10/15 22:10, Henrique de Moraes Holschuh wrote:
> On Fri, Oct 23, 2015, at 11:13, Carlos Alberto Lopez Perez wrote:
>> I was having trouble (crashes with the NVIDIA proprietary driver) on a
>> Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable)
> 
> This is very very likely to be braindamage on the NVIDIA driver, though.
> 
> Are you sure that driver is not doing something as idiotic as unlocking
> an already unlocked mutex ?
> 
> The proper fix in that case is _always_ to fix whatever is broken,
> because eventually it will run on something that has working hardware
> lock elision... and crash.
> 

I can't know, since I don't have access to the source code of the
driver, neither the debug symbols are available, so any attempt to get a
meaningful backtrace was hopeless.

At first I also thought it was the driver doing something wrong, but
then I found several reports of people with the same cryptic backtrace
than me saying that this was because of the TSX-NI bug of recent Intel
CPUs [1].

And effectively, after upgrading glibc to this one that disables TSX-NI
for broadwell it suddenly works as expected...

So this seems to suggest that effectively TSX-NI is buggy on this CPU.

In any case... Do you know of any program or test that I can run to
check if TSX-NI (both HLE and RTM) is working as it should or is still
buggy on this CPU? That way we can verify better if the problem is in
the CPU or in the driver.

>> I tried first to update the Intel microcode with the "unreleased" 0x13
>> microcode version but it didn't disabled the TSX-NI instructions [1]
>> neither the crashes.
> 
> Mobile Broadwell-H seems to disable TSX, while Desktop Broadwell-H
> doesn't.  That's why we blacklisted the whole thing: inconsistent
> behavior on the same microcode, and that behavior is itself inconsistent
> with the errata sheet that says such processors shouldn't even be able
> to advertise Intel TSX RTM in CPUID.
> 
> At the moment, we don't even know what is wrong with RTM in
> Broadwell/Broadwel-H/Broadwell-DE.  We do know some of what is wrong
> with HLE in Broadwell/-H/-DE (and it is really nasty), but HLE is not
> used by glibc in the first place, and the HLE erratum is supposedly
> worked around somehow (because it is documented to be so on the Xeon
> D-1500/Broadwell-DE) by the batch of microcode updates available in the
> kernel bugzilla bug report mentioned in this bug report.
> 
> Broadwell-H Microcode 0x13 is useful anyway because it fixes other
> critical errata that hangs/oopses the kernel: you box should be a _lot_
> more stable with it.  And at least one person reported that not all
> hangs were fixed by microcode 0x12, thus you probably should use keep
> using microcode 0x13 (or newer, should one become available).
> 

Good to know, thanks for the advice. I will keep using this 0x13
"unofficial" microcode until a new one is out.
I can't keep wondering why Intel is not releasing this :\


Regards!
--------

[1]
https://lists.archlinux.org/pipermail/arch-general/2015-April/038953.html

[signature.asc (application/pgp-signature, attachment)]

Message #77 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Carlos Alberto Lopez Perez <clopez@igalia.com>

To: Henrique de Moraes Holschuh <hmh@debian.org>, 800574@bugs.debian.org

Subject: Re: backport to sid/stable? (was RE: libc6: lock elision hazard on Intel Broadwell and Skylake)

Date: Mon, 26 Oct 2015 22:03:12 +0100

[Message part 1 (text/plain, inline)]

On 26/10/15 20:13, Carlos Alberto Lopez Perez wrote:
> On 23/10/15 22:10, Henrique de Moraes Holschuh wrote:
>> On Fri, Oct 23, 2015, at 11:13, Carlos Alberto Lopez Perez wrote:
>>> I was having trouble (crashes with the NVIDIA proprietary driver) on a
>>> Debian system with an i7-5775C and libc6=2.19-18+deb8u1 (stable)
>>
>> This is very very likely to be braindamage on the NVIDIA driver, though.
>>
>> Are you sure that driver is not doing something as idiotic as unlocking
>> an already unlocked mutex ?
>>
>> The proper fix in that case is _always_ to fix whatever is broken,
>> because eventually it will run on something that has working hardware
>> lock elision... and crash.
>>
> 
> I can't know, since I don't have access to the source code of the
> driver, neither the debug symbols are available, so any attempt to get a
> meaningful backtrace was hopeless.
> 
> At first I also thought it was the driver doing something wrong, but
> then I found several reports of people with the same cryptic backtrace
> than me saying that this was because of the TSX-NI bug of recent Intel
> CPUs [1].
> 
> And effectively, after upgrading glibc to this one that disables TSX-NI
> for broadwell it suddenly works as expected...
> 
> So this seems to suggest that effectively TSX-NI is buggy on this CPU.
> 
> In any case... Do you know of any program or test that I can run to
> check if TSX-NI (both HLE and RTM) is working as it should or is still
> buggy on this CPU? That way we can verify better if the problem is in
> the CPU or in the driver.
> 

I'm re-reading your explanation [2] about programs crashing with SIGSEV
in __lll_unlock_elision when TSX is enabled to be caused by the program
itself trying to unlock an already unlocked lock. That would explain
everything, and will point indeed to a bug in the NVIDIA driver rather
than in the CPU.

Also, this specific model of CPU (i7-5775C) for what I have been reading
seems to have fixed TSX-NI support. At least the ark page of Intel still
advertises it [3]. In any case I'm still interested in testing this to
be 100% sure. If you know about any test program that I can run, please
let me know about it.

Cheers
------

[2] https://bugzilla.kernel.org/show_bug.cgi?id=103351#c86
[3]
http://ark.intel.com/products/88040/Intel-Core-i7-5775C-Processor-6M-Cache-up-to-3_70-GHz

[signature.asc (application/pgp-signature, attachment)]

Message #82 received at 800574-close@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurel32@debian.org>

To: 800574-close@bugs.debian.org

Subject: Bug#800574: fixed in glibc 2.21-1

Date: Tue, 01 Dec 2015 10:22:26 +0000

Source: glibc
Source-Version: 2.21-1

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 800574@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aurelien Jarno <aurel32@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 01 Dec 2015 00:17:43 +0100
Source: glibc
Binary: libc-bin libc-dev-bin libc-l10n glibc-doc glibc-source locales locales-all nscd multiarch-support libc6 libc6-dev libc6-dbg libc6-pic libc6-udeb libc6.1 libc6.1-dev libc6.1-dbg libc6.1-pic libc6.1-udeb libc0.3 libc0.3-dev libc0.3-dbg libc0.3-pic libc0.3-udeb libc0.1 libc0.1-dev libc0.1-dbg libc0.1-pic libc0.1-udeb libc6-i386 libc6-dev-i386 libc6-sparc libc6-dev-sparc libc6-sparc64 libc6-dev-sparc64 libc6-s390 libc6-dev-s390 libc6-amd64 libc6-dev-amd64 libc6-powerpc libc6-dev-powerpc libc6-ppc64 libc6-dev-ppc64 libc6-mips32 libc6-dev-mips32 libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386 libc0.1-dev-i386 libc6-x32 libc6-dev-x32 libc6-i686 libc6-xen libc0.1-i686 libc0.3-i686 libc0.3-xen libc6.1-alphaev67 libnss-dns-udeb libnss-files-udeb
Architecture: source
Version: 2.21-1
Distribution: unstable
Urgency: medium
Maintainer: GNU Libc Maintainers <debian-glibc@lists.debian.org>
Changed-By: Aurelien Jarno <aurel32@debian.org>
Description:
 glibc-doc  - GNU C Library: Documentation
 glibc-source - GNU C Library: sources
 libc-bin   - GNU C Library: Binaries
 libc-dev-bin - GNU C Library: Development binaries
 libc-l10n  - GNU C Library: localization files
 libc0.1    - GNU C Library: Shared libraries
 libc0.1-dbg - GNU C Library: detached debugging symbols
 libc0.1-dev - GNU C Library: Development Libraries and Header Files
 libc0.1-dev-i386 - GNU C Library: 32bit development libraries for AMD64
 libc0.1-i386 - GNU C Library: 32bit shared libraries for AMD64
 libc0.1-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.1-pic - GNU C Library: PIC archive library
 libc0.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3    - GNU C Library: Shared libraries
 libc0.3-dbg - GNU C Library: detached debugging symbols
 libc0.3-dev - GNU C Library: Development Libraries and Header Files
 libc0.3-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.3-pic - GNU C Library: PIC archive library
 libc0.3-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3-xen - GNU C Library: Shared libraries [Xen version]
 libc6      - GNU C Library: Shared libraries
 libc6-amd64 - GNU C Library: 64bit Shared libraries for AMD64
 libc6-dbg  - GNU C Library: detached debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files
 libc6-dev-amd64 - GNU C Library: 64bit Development Libraries for AMD64
 libc6-dev-i386 - GNU C Library: 32-bit development libraries for AMD64
 libc6-dev-mips32 - GNU C Library: o32 Development Libraries for MIPS
 libc6-dev-mips64 - GNU C Library: 64bit Development Libraries for MIPS64
 libc6-dev-mipsn32 - GNU C Library: n32 Development Libraries for MIPS64
 libc6-dev-powerpc - GNU C Library: 32bit powerpc development libraries for ppc64
 libc6-dev-ppc64 - GNU C Library: 64bit Development Libraries for PowerPC64
 libc6-dev-s390 - GNU C Library: 32bit Development Libraries for IBM zSeries
 libc6-dev-sparc - GNU C Library: 32bit Development Libraries for SPARC
 libc6-dev-sparc64 - GNU C Library: 64bit Development Libraries for UltraSPARC
 libc6-dev-x32 - GNU C Library: X32 ABI Development Libraries for AMD64
 libc6-i386 - GNU C Library: 32-bit shared libraries for AMD64
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-mips32 - GNU C Library: o32 Shared libraries for MIPS
 libc6-mips64 - GNU C Library: 64bit Shared libraries for MIPS64
 libc6-mipsn32 - GNU C Library: n32 Shared libraries for MIPS64
 libc6-pic  - GNU C Library: PIC archive library
 libc6-powerpc - GNU C Library: 32bit powerpc shared libraries for ppc64
 libc6-ppc64 - GNU C Library: 64bit Shared libraries for PowerPC64
 libc6-s390 - GNU C Library: 32bit Shared libraries for IBM zSeries
 libc6-sparc - GNU C Library: 32bit Shared libraries for SPARC
 libc6-sparc64 - GNU C Library: 64bit Shared libraries for UltraSPARC
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc6-x32  - GNU C Library: X32 ABI Shared libraries for AMD64
 libc6-xen  - GNU C Library: Shared libraries [Xen version]
 libc6.1    - GNU C Library: Shared libraries
 libc6.1-alphaev67 - GNU C Library: Shared libraries (EV67 optimized)
 libc6.1-dbg - GNU C Library: detached debugging symbols
 libc6.1-dev - GNU C Library: Development Libraries and Header Files
 libc6.1-pic - GNU C Library: PIC archive library
 libc6.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales    - GNU C Library: National Language (locale) data [support]
 locales-all - GNU C Library: Precompiled locale data
 multiarch-support - Transitional package to ensure multiarch compatibility
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 672774 712074 715059 717544 722885 753909 764692 766877 775179 781245 782198 785796 788352 788799 793641 796105 797538 797831 798064 798316 799418 799478 800574 800846 801691 802256 805730 805836
Changes:
 glibc (2.21-1) unstable; urgency=medium
 .
   [ Aurelien Jarno ]
   * testsuite-checking/expected-results-mips64el-linux-gnu-*: allow
     nptl/tst-cancel24-static to fail on mips64el.  It's an upstream regression
     only affecting static binaries currently under investigation.
   * patches/hppa/submitted-mathdef.diff: update to include the ABI baseline
     changes.
   * testsuite-checking/expected-results-*kfreebsd-gnu-*: re-add rt/tst-shm as
     it seems it can still occasionally fail on the buildds.
 .
 glibc (2.21-0experimental4) experimental; urgency=medium
 .
   [ Aurelien Jarno ]
   * testsuite-checking/expected-results-*kfreebsd-gnu-*: re-add tst-getpid1
     and tst-getpid2 as it seems they can still occasionally fail on the
     buildds.
   * testsuite-checking/expected-results-mips64el-linux-gnu-libc: rename into
     testsuite-checking/expected-results-mips64el-linux-gnuabi64-libc.
   * testsuite-checking/expected-results-{arm,mips}*: allow nptl/tst-stack4 to
     fail. It's a new test which fails intermitently on the buildds and a known
     upstream problem.
   * patches/hppa/submitted-mathdef.diff: new patch from John David Anglin to
     define __NO_LONG_DOUBLE_MATH on hppa.  Closes: #805836.
   * patches/hppa/cvs-inline-syscall-rewrite.diff: new patch backported from
     upstream as requested by John David Anglin.
   * patches/hppa/cvs-sysdep-errno.diff: new patch backported from upstream as
     requested by John David Anglin.
   * testsuite-checking/expected-results-hppa-linux-gnu-libc: update testsuite
     result, from John David Anglin.
   * testsuite-checking/*{arm,mips,hppa}*: allow nptl/tst-cancel24-static to
     fail on armel, armhf, hppa, mips, mipsel. It's an upstream regression
     only affecting static binaries currently under investigation.
 .
   [ Samuel Thibault ]
   * patches/hurd-i386/tg-tls-threadvar.diff: Update, to fix recursion while
     accessing TLS while locking for accessing TLS.
   * patches/hurd-i386/tg-context_functions.diff: Update, to fix sigprocmask
     visibility.
   * patches/hurd-i386/cvs-hidden.diff: New patch, to fix build with hidden
     support.
   * sysdeps/hurd-i386.mk: Disable libc0.3-i686 and libc0.3-xen build for now,
     to get 2.21 out against the binutils version which broke them.
 .
 glibc (2.21-0experimental3) experimental; urgency=medium
 .
   [ Aurelien Jarno ]
   * patches/hppa/cvs-allocatestack-stacktop.diff: new patch from upstream
     to fix a set-but-unused warning in nptl/allocatestack.c, causing a
     build failure.
   * patches/hppa/local-stack-grows-up.diff: rebase.
   * patches/any/cvs-tls-dtv.diff: new patch from upstream to fix DTV race,
     assert, and DTV_SURPLUS Static TLS limit.  This also reduces the failure
     rate of nptl/tst-stack4.  Closes: #793641.
   * Add expected testsuite result for mips64el:
     - testsuite-checking/expected-results-mips64el-linux-gnu-libc
     - testsuite-checking/expected-results-mips64el-linux-gnuabin32-mipsn32
     - testsuite-checking/expected-results-mipsel-linux-gnu-mips32
   * patches/kfreebsd/local-sysdeps.diff, patches/kfreebsd/local-fbtl.diff:
     update to revision 5844 (from glibc-bsd):
     - Update to glibc 2.21.
     - Define F_DUP2FD_CLOEXEC.  Closes: #712074.
     - Define SOCK_CLOEXEC and SOCK_NONBLOCK.
     - Wire-up accept4.  Closes: #722885.
   * sysdeps/kfreebsd-{amd64,i386}.mk: configure with --disable-werror.
   * patches/kfreebsd/local-nscd-no-sockcloexec.diff: Drop.
   * patches/kfreebsd/local-getaddrinfo-freebsd-kernel.diff: improve and remove
     a warning.
   * patches/kfreebsd/local-tst-auxv.diff: new patch to disable AT_EXECFN
     testing in tst-auxv when it is not defined.
   * patches/any/cvs-rfc3542-advanced-api.diff: new patch from usptream to
     add missing Advanced API (RFC3542) (1) defines.  Closes: #753909.
   * debian/rules: don't put debug files from libc0.1-i386 and libc6-mips32
     into libc0.1-dbg or libc6-dbg.
   * patches/hppa/cvs-atomic.diff, patches/hppa/cvs-inline-syscall.diff: new
     patches from upstream to improve atomic and inline syscalls on HPPA
     (closes: #799478).
   * rules.d/build.mk: don't run the testsuite with make -k, as a build
     failure in the testsuite, otherwise build failures cause the regression
     comparison to be entirely skipped.
   * testsuite-checking/expected-results-*kfreebsd-gnu-*: update testsuite
     results.
   * patches/any/cvs-check-localplt.diff: new patch from upstream to fix
     check-localplt test with recent binutils version on x86.
   * patches/hppa/submitted-gmon-start.diff: new patch from upstream to
     fix __gmon_start__ symbol proliferation on hppa.  Closes: #805730.
   * Update from upstream stable branch:
     - patches/any/cvs-make-typo.diff: Merged.
     - Fix FTBFS with libselinux 2.4.
 .
   [ Samuel Thibault ]
   * patches/hurd-i386/tg-pagesize.diff: Refresh.
   * patches/hurd-i386/submitted-handle-eprototype.diff: Refresh.
   * patches/hurd-i386/tg-posix_thread.diff: Update, to define
     _POSIX_THREAD_KEYS_MAX, _POSIX_THREAD_DESTRUCTOR_ITERATIONS and
     _POSIX_THREAD_THREADS_MAX.
 .
 glibc (2.21-0experimental2) experimental; urgency=medium
 .
   [ Samuel Thibault ]
   * Symbol versions which contain _DEBIAN_ are unexpected by upstream scripts.
     Add hurd-i386-only patches/hurd-i386/local-versions-hack.diff to work
     around the issue.  Also take the opportunity of the upstream version bump
     to bump the versions to GLIBC_2_21, which will allow one to remove the
     _DEBIAN_ hacks once packages are rebuilt.
   * patches/hurd-i386/unsubmitted-libpthread-semaphore.h.diff: Remove
     libpthread/sysdeps/i386/bits/semaphore.h, now that hurd Implies
     libpthread/sysdeps/generic. Move libpthread/include/semaphore.h into
     libpthread/sysdeps/pthread/semaphore.h instead of the latter just
     including the former, since the latter is what gets installed.
   * patches/hurd-i386/cvs-cache-mach_host_self.diff: New patch to avoid port
     count issue on the host port.
   * patches/hurd-i386/unsubmitted-gnumach.defs.diff: Also build
     task_notify.defs stubs.  Drop unneeded change.
   * libc0.3.symbols.hurd-i386: Update.
   * patches/hurd-i386/local-mach_print.diff: New patch to export mach_print.
 .
   [ Aurelien Jarno ]
   * rules.d/debhelper.mk: replace GLIBC_VERSION before LIBC.  Closes:
     #797538.
   * Drop loongson-2f flavour on mipsel as this machine is not supported
     anymore (default to R2 ISA).
   * kfreebsd/local-sysdeps.diff: update to revision 5772 (from glibc-bsd).
     Closes: #764692, #785796.
   * testsuite-checking/expected-results-mips*: allow the new tst-audit9
     fail, like the others tst-auditX.
   * testsuite-checking/expected-results-mips(el)-linux-gnu-libc: allow
     conformtest for sys/stat.h to fail for O32 ABI. They were previously
     under the failing test run-conformtest.out, but it has been lost in
     the conversion to the new format.
   * testsuite-checking/expected-results-mips*: sort the files. Remove
     failures due to old kernel now that all buildds run jessie.
   * debhelper.in/locales-all.prerm: do not specify a path to check for
     locale-gen.
   * libc6.1.symbols.alpha: remove invoke_dynamic_linker from libpcprofile.so.
     It has disappeared, but it is a private library.
   * Remove debver2localesdep.pl, it is unused since 2.19-16.
   * Use $(GLIBC_VERSION) for shlib, instead of defining the version in a
     separate shlibver file.
   * Remove completely outdated README, README.source and TODO files.
   * rules.d/debhelper.mk: use the default compression format for libc6,
     libc-bin and multiarch-support. Nowadays deboostrap is able to handle
     the xz format and modern distributions also support it. Anyway almost
     all packages installed by debootstrap are now using the xz format.
   * Bump debhelper compatibility to level 9. This brings compressed debug
     file using the build-id instead of a fixed path. This is much more
     multiarch friendly.
   * control.in/*: remove pre-squeeze conflicts.
   * libc-bin, libc-dev-bin: Recommends the manpages package and add lintian
     override for missing manpages.
   * sysdeps/s390x.mk: --enable-lock-elision.
   * testsuite-checking/expected-results-x86_64-linux-gnux32-*: allow
     conformtest for headers with tv_nsec to fail for x32. The type
     non-compliance is intentional. These tests were previously marked as
     failing under the run-conformtest.out, but they have been lost during
     the conversion to the new format.
   * testsuite-checking/compare.sh: re-enable failures in case of regressions.
   * rules.d/build.mk: don't require flavours to be tested before being
     installed. They are still tested when calling the build-arch or
     binary-arch targets, but not anymore when calling the build-indep or
     binary-indep targets.
   * patches/hppa/cvs-alloca-werror.diff: new patch from upstream to fix a
     build failure.
   * debhelper.in/libc.preinst: fix up error message for too old Linux
     kernels.  Closes: #800846.
   * patches/any/cvs-ld_pointer_guard.diff: new patch from upstream to
     unconditionally disable LD_POINTER_GUARD.  Closes: #798316, #801691.
   * patches/any/cvs-mangle-tls_dtor_list.diff: new patch from upstream to
     mangle function pointers in tls_dtor_list.  Closes: #802256.
   * Update Brazilian Portuguese debconf translation, by Adriano Rafael
     Gomes.  Closes: #799418.
 .
   [ Steven Chamberlain ]
   * sysdeps/kfreebsd.mk: find kfreebsd-kernel-headers in multiarch path.
     Closes: #672774, #798064.
 .
   [ Helmut Grohne ]
   * Fix some issues with stage 1.  Closes: #797831.
 .
   [ Adam Conrad ]
   * debian/patches/arm/local-arm-futex.diff: Lie about the minimum kernel
     support for futex_atomic_cmpxchg_inatomic to restore the  previous state
     and fix the pulsesink (and others) regression on ARM (closes: #788799)
 .
   [ Henrique de Moraes Holschuh ]
   * Replace patches/amd64/local-blacklist-on-TSX-Haswell.diff by
     local-blacklist-for-Intel-TSX.diff also blacklisting some Broadwell
     models.  Closes: #800574.
 .
 glibc (2.21-0experimental1) experimental; urgency=medium
 .
   [ Samuel Thibault ]
   * patches/hurd-i386/cvs-libpthread.diff: Update from upstream.
   * patches/hurd-i386/cvs-libpthread-dlopen.diff: Merged.
   * patches/hurd-i386/cvs-libpthread-libc-lockP2.diff: Merged.
   * patches/hurd-i386/cvs-bind_umask.diff: Merged.
   * patches/hurd-i386/cvs-fork_ss_hang.diff: Merged.
   * patches/hurd-i386/cvs-munmap-0.diff: Merged.
   * patches/hurd-i386/cvs-static-dlopen.diff: Merged.
   * patches/hurd-i386/cvs-tcbhead_t.diff: Merged.
   * patches/hurd-i386/cvs-libpthread_versions.diff: Rebased.
   * patches/hurd-i386/local-disable-tst-xmmymm.diff: Dropped.
   * patches/hurd-i386/local-hurdsig-global-dispositions-version.diff: Rebased.
   * patches/hurd-i386/submitted-exec_filename.diff: Rebased.
   * patches/hurd-i386/submitted-net.diff: Rebased.
   * patches/hurd-i386/tg-EIEIO-fr.diff: Rebased.
   * patches/hurd-i386/tg-af_local_strlen.diff: Rebased.
   * patches/hurd-i386/tg-chflags.diff: Rebased.
   * patches/hurd-i386/tg-tls-threadvar.diff: Update.
   * patches/hurd-i386/tg-tls.diff: Rebased.
   * patches/hurd-i386/tg-tls_thread_leak.diff: Rebased.
   * patches/hurd-i386/unsubmitted-NO_HIDDEN.diff: Rebased.
   * patches/hurd-i386/tg-no-hp-timing.diff: Update.
   * patches/series: Re-enable all hurd patches.
   * patches/hurd-i386/libpthread-versions.diff: New patch, updates to new
     version engine.
   * patches/hurd-i386/cvs-revert-gnu-gnu-cleanup.diff: New patch, reverts
     cleanup of the gnu-gnu hack.
   * patches/hurd-i386/libpthread_pthread_types.diff: New patch, fixes
     inclusion of pthread_types.h
   * patches/hurd-i386/unsubmitted-libc_alloca_cutoff.diff: New patch,
     implements alloca cutoff limit.
   * patches/hurd-i386/cvs-unwind-resume.diff: New patch, fixes unwind-resume
     build.
   * patches/hurd-i386/unsubmitted-libpthread-semaphore.h.diff: New patch,
     fixes semaphore header inclusion.
   * patches/hurd-i386/unsubmitted-timer_routines.diff: New patch, fixes
     timer_routines build.
   * patches/hurd-i386/cvs-libc-modules.h.diff: New patch, adds missing
     dependency on libc-modules.h.
   * patches/hurd-i386/cvs-warnings.diff: New patch, fixes warnings.
   * patches/hurd-i386/cvs-check-local-headers.diff: New patch, clears spurious
     local-header warnings.
   * sysdeps/hurd.mk: Disable -Werror since MIG currently generates warnings.
   * testsuite-checking/expected-results-{i586-gnu-libc,i686-gnu-
     {i386,i686,xen}}: update testsuite results
 .
   [ Adam Conrad ]
   * debian/{rules.d/debhelper.mk,sysdeps/*}: Define per-platform pldd
     variable to control installation of usr/bin/pldd in libc-bin, and
     leverage the same trick to decide to install usr/lib/pt_chown too.
   * debian/patches/kfreebsd/local-no-pldd.diff: Drop, no longer used.
   * debian/patches/alpha/submitted-PTR_MANGLE.diff: Use IS_IN macros.
   * debian/patches/powerpc/cvs-ppc-sqrt.diff: Fix sqrt() on powerpc.
   * debian/patches/powerpc/cvs-ppc-sqrtf.diff: Likewise for sqrtf().
   * debian/patches/powerpc/cvs-ppc-pow.diff: Likewise for pow().
   * debian/patches/powerpc/cvs-ppc-feraiseexcept.diff: Fix inline
     feraiseexcept and feclearexcept macro input conversion on PPC.
   * debian/patches/any/submitted-longdouble.diff: Refresh for above.
   * debian/patches/any/local-disable-test-tgmath2.diff: Likewise.
   * debian/patches/any/cvs-logbl-accuracy.diff: Fix ldbl-128ibm logbl.
   * debian/patches/powerpc/local-math-logb.diff: Refresh and move to
     debian/patches/any/local-math-logb.diff, as it's not PPC-specific.
   * debian/patches/any/cvs-localplt-new-readelf.diff: Preemptively
     fix localplt test breakage with binutils 2.26 before it lands.
   * debian/patches/any/cvs-make-typo.diff: Fix typo in elf/Makefile.
   * debian/patches/powerpc/cvs-power7-strncpy.diff: Optimize strncpy
     for POWER7 drastically (10-70%) on strings longer than 16 chars.
   * debian/patches/powerpc/cvs-ppc-tabort-le.diff: Fix TABORT encoding
     when building on toolchains without HTM support (no-op on gcc-4.9)
   * debian/patches/arm/cvs-arm-sfi_breg.diff: Fix LDR_GLOBAL macro.
   * debian/patches/arm/cvs-memcpy-memmove-always-bx.diff: Fix memcpy
     and memmove for the ARM_ALWAYS_BX class of hardware like ArmadaXP.
   * debian/{control.in/*,debhelper.in/*,rules.d/*}: Stop hardcoding our
     upstream version all over the place and use GLIBC_VERSION instead.
   * debian/debhelper.in/libc.preinst: Unconditionally wipe ld.so.cache
     on major version upgrades, which is significantly less error-prone.
 .
   [ Aurelien Jarno ]
   * debian/patches/any/local-libgcc-compat-main.diff: Fix definition of
     __floatdisf for sparc.
   * debian/patches/any/local-libgcc-compat-ports.diff: Fix definition of
     __floatdisf for mips. Remove usage of INTUSE (Closes: #782198).
   * debian/sysdeps/linux.mk, debhelper.in/libc.preinst: bump minimal Linux
     kernel version to 3.2 (ie the version in Wheezy).
   * debian/patches/localedata/locale-C.diff: fix d_fmt time format (Closes:
     #775179).
   * Create source tarball in a deterministic manner: adjust file modification
     time, user, group, permissions, and file order (addresses: #783210).
   * Update from upstream stable branch:
     - Fix a buffer overflow in getanswer_r (CVE-2015-1781). Closes: #796105.
   * sysdeps/linux.mk: don't build pt_chown (CVE-2013-2207). Closes: #717544.
   * Move translation to a new libc-l10n package from the locales packages.
     Add a dependency from locales and locales-all to libc-l10n, so that they
     both provide the same feature. Closes: #788352.
   * control.in/main: Bump Standards-Version to 3.9.6 (no changes).
 .
   [ Breno Leitao ]
   * Remove --without-cvs that is not used anymore as a valid configuration.
     It was removed in commit 92963737c4376bcfd65235d5c325fa7f48302f89
     (Closes: #781245).
 .
   [ Matthias Klose ]
   * Fix multilib enabled stage1 cross builds (closes: #766877).
 .
 glibc (2.21-0experimental0) experimental; urgency=medium
 .
   * New upstream release: version 2.21, with git updates up to 2015-02-10:
     - debian/patches/git-updates.diff: Updated.
     - debian/patches/all/submitted-po-fr-fixes.diff: Rebased.
     - debian/patches/alpha/cvs-__pointer_chk_guard.diff: Merged.
     - debian/patches/alpha/cvs-unwind-backtrace.diff: Merged.
     - debian/patches/alpha/local-gcc4.1.diff: Rebased.
     - debian/patches/alpha/local-lowlevellock.diff: Dropped.
     - debian/patches/alpha/local-string-functions.diff: Rebased.
     - debian/patches/alpha/submitted-PTR_MANGLE.diff: Rebased.
     - debian/patches/alpha/submitted-dl-support.diff: Rebased.
     - debian/patches/alpha/submitted-lll_futex_timed_wait_bitset.diff: Dropped.
     - debian/patches/alpha/submitted-rtld-fPIC.diff: Rebased.
     - debian/patches/amd64/cvs-slow-sse42.diff: Merged.
     - debian/patches/amd64/local-blacklist-on-TSX-Haswell.diff: Rebased.
     - debian/patches/amd64/submitted-rwlock-stack-imbalance.diff: Dropped.
     - debian/patches/any/cvs-check_pf-infinite-loop.diff: Merged.
     - debian/patches/any/cvs-getnetbyname.diff: Merged.
     - debian/patches/any/cvs-pie-lt_executable.diff: Merged.
     - debian/patches/any/cvs-regex-alloca.diff: Merged.
     - debian/patches/any/cvs-resolv-first-query-failure.diff: Merged.
     - debian/patches/any/cvs-socketcall-syscall.diff: Merged.
     - debian/patches/any/cvs-strtod.diff: Merged.
     - debian/patches/any/cvs-vfprintf.diff: Merged.
     - debian/patches/any/cvs-wordexp.diff: Merged.
     - debian/patches/any/cvs-wprintf.diff: Merged.
     - debian/patches/any/cvs-wscanf.diff: Merged.
     - debian/patches/any/local-disable-libnss-db.diff: Rebased.
     - debian/patches/any/local-disable-test-tgmath2.diff: Rebased.
     - debian/patches/any/local-libgcc-compat-ports.diff: Rebased.
     - debian/patches/any/local-libpic.diff: Rebased.
     - debian/patches/any/local-no-SOCK_NONBLOCK.diff: Rebased.
     - debian/patches/any/local-no-pagesize.diff: Rebased.
     - debian/patches/any/local-rtlddir-cross.diff: Rebased.
     - debian/patches/any/local-stdio-lock.diff: Rebased.
     - debian/patches/any/local-sysctl.diff: Rebased.
     - debian/patches/any/submitted-argp-attribute.diff: Rebased.
     - debian/patches/any/submitted-bits-fcntl_h-at.diff: Rebased.
     - debian/patches/any/submitted-longdouble.diff: Rebased.
     - debian/patches/any/submitted-nl_langinfo-static.diff: Merged.
     - debian/patches/any/submitted-ptsname_r-uninitialized-memory.diff: Merged.
     - debian/patches/any/submitted-resolv-ipv6-nameservers.diff: Rebased.
     - debian/patches/any/submitted-sysdeps-auxv.diff: Merged.
     - debian/patches/any/unsubmitted-scanf-includes.diff: Rebased.
     - debian/patches/any/unsubmitted-tst-ftell-locale.diff: Dropped.
     - debian/patches/any/unsubmitted-tst-tlsmod-as-needed.diff: Merged.
     - debian/patches/arm/local-ioperm.diff: Rebased.
     - debian/patches/arm/local-lowlevellock.diff: Dropped.
     - debian/patches/arm/local-sigaction.diff: Rebased.
     - debian/patches/arm/local-vfp-sysdeps.diff: Rebased.
     - debian/patches/arm/unsubmitted-ldconfig-cache-abi.diff: Rebased.
     - debian/patches/arm64/cvs-includes-cleanup.diff: Merged.
     - debian/patches/arm64/submitted-align.diff: Merged.
     - debian/patches/arm64/submitted-setcontext.diff: Merged.
     - debian/patches/arm64/submitted-tst-setcontext.diff: Merged.
     - debian/patches/hppa/cvs-sigrtmin.diff: Merged.
     - debian/patches/hppa/local-atomic.diff: Dropped.
     - debian/patches/hppa/local-elf-make-cflags.diff: Rebased.
     - debian/patches/hppa/local-fcntl-osync.diff: Rebased.
     - debian/patches/hppa/local-fpu.diff: Rebased.
     - debian/patches/hppa/local-inlining.diff: Rebased.
     - debian/patches/hppa/local-lowlevellock.diff: Dropped.
     - debian/patches/hppa/local-pthread_spin_unlock.diff: Rebased.
     - debian/patches/hppa/local-setjmp-namespace.diff: Dropped.
     - debian/patches/hppa/local-shmlba.diff: Rebased.
     - debian/patches/hppa/local-stack-grows-up.diff: Rebased.
     - debian/patches/hurd-i386/tg-libpthread_depends.diff: Rebased.
     - debian/patches/i386/submitted-i686-timing.diff: Rebased.
     - debian/patches/kfreebsd/local-fbtl-depends.diff: Rebased.
     - debian/patches/kfreebsd/local-fbtl.diff: Rebased.
     - debian/patches/kfreebsd/local-scripts.diff: Rebased.
     - debian/patches/kfreebsd/local-sysdeps.diff: Rebased.
     - debian/patches/kfreebsd/submitted-waitid.diff: Rebased.
     - debian/patches/locale/locale-print-LANGUAGE.diff: Rebased.
     - debian/patches/locale/submitted-XDR-revert.diff: Merged.
     - debian/patches/localedata/sort-UTF8-first.diff: Rebased.
     - debian/patches/localedata/supported.diff: Rebased.
     - debian/patches/m68k/local-fpic.diff: Rebased.
     - debian/patches/m68k/local-mathinline_h.diff: Rebased.
     - debian/patches/m68k/local-reloc.diff: Rebased.
     - debian/patches/mips/local-lowlevellock.diff: Dropped.
     - debian/patches/mips/local-r10k.diff: Rebased.
     - debian/patches/mips/submitted-rld_map.diff: Rebased.
     - debian/patches/powerpc/cvs-ibm-branch.diff: Dropped.
     - debian/patches/sparc/local-fork.diff: Dropped.
     - debian/patches/sparc/local-sparcv9-target.diff: Rebased.
   * Drop some hppa patches that Carlos O'Donell claims are no longer needed:
     - debian/patches/hppa/local-EAGAIN.diff: Dropped.
     - debian/patches/hppa/local-fanotify_mark-5i.diff: Dropped.
     - debian/patches/hppa/submitted-fadvise64_64.diff: Dropped.
     - debian/patches/hppa/submitted-nptl-carlos.diff: Dropped.
   * debian/*: Update occurences of 2.19 to 2.21 and update symbols to match.
   * debian/patches/any/cvs-vismain-pie.diff: Compile vismain with -fPIE
     and link with -pie to fix testsuite failure with the new binutils.
   * debian/patches/any/local-libgcc-compat-abilists.diff: Fix the ablists
     to match the symbols added in local-libgcc-compat* for the testsuite.
   * debian/patches/sh4/local-fpscr_values.diff: Make the sh abilist match.
   * debian/{control.in/main,rules}: Switch to gcc-4.9 on all architectures.
   * debian/patches/any/local-tester-gcc-4.9.diff: Fix gcc-4.9 regression.
   * debian/patches/any/local-xfail-stdlib-linkns.diff: XFAIL this test due
     to building with pt_chown, which we should revisit very, very soon.
   * debian/sysdeps/*: --enable-lock-elision on PPC targets (LP: #1414819)
   * debian/libc*.symbols*: Remove local __invoke_dynamic_linker__ symbol,
     which no longer shows up in random support libraries' symbol tables.
   * debian/sysdeps/*: Neither ports nor nptl are considered add-ons anymore.
   * debian/{rules.d/build.mk,testsuite-checking/*}: Adjust for upstream's
     new testsuite, and convert old expected-results-* to match new output.
   * debian/testsuite-checking/*: Let arm64 fail the tests indicated by the
     upstream port maintainer as broken, and let i386 fail tst-cleanupx4.
   * debian/debhelper.in/glibc-doc.install: Install changelogs that exist.
   * debian/patches/i386/submitted-i686-timing.diff: Fix -Wundef warnings.
   * debian/patches/arm/unsubmitted-ldso-abi-check.diff: Fix build failures
     from format mismatches, uninitialised variables, and const conversions.
   * debian/rules.d/debhelper.mk: Fix bootstrap libdirs (Closes: #715059)
   * debian/patches/arm/unsubmitted-ldconfig-cache-abi.diff: Same as above.
   * Other than two hurd-i386 patches required as scaffolding for others,
     all the hurd-i386 patches are disabled, so this build *will* fail there.
   * kfreebsd's sysdeps patches almost certainly need updating for 2.21 too.
   * Failing on testsuite failures is disabled to attempt to get full builds.
Checksums-Sha1:
 00a32a01e48e8ef0535565306d0b28279fa36052 8198 glibc_2.21-1.dsc
 981a0db9088d09677f67e7d5021fc24d5e973156 1016592 glibc_2.21-1.debian.tar.xz
Checksums-Sha256:
 a293aaf7a7d59b8b0541965df6c89d6fb7f9da304c70f32717d5efd3dd02d5cd 8198 glibc_2.21-1.dsc
 975e16703caceaaff712be9da23eed8689a45579204fcf803750ce73e043ad6a 1016592 glibc_2.21-1.debian.tar.xz
Files:
 a1e6680f72e9aa554239546009d53885 8198 libs required glibc_2.21-1.dsc
 3225b3e92bb141699d47923115782dd4 1016592 libs required glibc_2.21-1.debian.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWXUj7AAoJELqceAYd3YybJGIQALm17R81ofby+W/yv84J/SEh
Fck5fRn8jgaCoPBLfNzkPp2tYyu0rq9eIjYihJC4noSSlDeC7CmQyItAa7sbclit
z+GdhdSwoQa4WP+QRSHBDpkdJGBgDoKE1zTuy00fVu5cvRNMbm8akHUV8ftlqdoc
1qQ1SPwchdDyEQi1FEYwMEmwxEOc/OoQFziG1BqOiuNsF2qvwYR20OYFlMtiwcwO
xN6ukybA5ZskTjTX/3KpBl54rJkYxfOJRppKHmrFfBYgxGWBU7LBEzA7+CL0T4tK
1QjsNqmULiyeFaVbJvVwmLrIZvfAnYRWyvDN0Vu6x5B0O6E328XYOzIYd6CStnT5
bIHrIukVGlZlhM8MOU7hjAKjJOpHwuAhfYQId8FNPjUZn0hCukhxtK1qO1nInBr/
ztbI3R8Q/KVf9x5t1vnzVRbdsL4aRRVhd3+p/OekLmyW7paTkFJV60quEOFHTisE
+ugDmGkFMDXqBXXhfyrbLH+uuOmwTg9lTvXo6+V1G0HZQo/ERTW01qgTSpAvCCRj
0oo0KGHNalvIwW8hhVQkLuCO5c0TINY6CeEZvQK9HFAsDFHCZLUqfGFZP0Vz6dsU
KO51X+XLetTynzlFpQw1+VU7vCgOpDWX7F3bpi07217ew5rr5nk7hbw75ovq/HAC
+e9kwAibDsLZ3ceFtedR
=CCOx
-----END PGP SIGNATURE-----

Message #87 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Andreas Beckmann <anbe@debian.org>

To: 800574@bugs.debian.org

Cc: jhaand@xs4all.nl, 807244@bugs.debian.org

Subject: Re: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)

Date: Mon, 07 Dec 2015 23:26:18 +0100

Dear libc maintainers,

we recently got a bug report regarding the TSX-NI / lock elision bug in
combination with the non-free nvidia driver (#807244). Since that is
supposed to be fixed with the libc in experimental (and now sid as
well), perhaps you could take a look why this still happens.
Several forum posts denote that "compiling glibc without
--enable-lock-elision" works around that issue.

A few ideas from my side, but since I don't have the hardware to test, I
cannot check anything:
* that specific CPU needs to be blacklisted / is incorrectly whitelisted
* nvidia utilizes a code path in libc that is not covered by the current
patch (and that code path is not used by any other application)
* nvidia does call something it shouldn't call directly ... thus
circumenting the runtime-disabling of the specific routines in libc6
* nvidia code does issue the problematic instructions itself (but the
backtrace points to libc, so this sounds unlikely)

Is there some way to check at runtime how lock elision is handled by
libc (on a concrete system)?

Andreas

On 2015-12-06 17:53, Jelle Haandrikman wrote:
> On a system with an Nvidia GTX 970, Intel Skylake i5-6600k running driver
> 352.63-1 (experimental) several programs crash due to TSX-NI / elision unlock.
> This affects sddm, unlocking kscreen, vlc and deleting files using dolphin.
> 
> Other people also have found this issue.
> http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/nvidia-linux/825702-nvidia-s-latest-binary-driver-is-causing-problems-for-some-skylake-linux-users
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=800574 #800574
> https://devtalk.nvidia.com/default/topic/893325/newest-and-beta-linux-driver-causing-segmentation-fault-core-dumped-on-all-skylake-platforms/
> 
> Bug #800574 suggest to disable elisian-unlock in glibc. Which is already
> incorporated in experimental. This does not alleviate the issue. See the "steps
> to reproduce" below. The same bug suggests that the nvidia driver still has
> problems. I also run intel-microcode update, but that doesn't solve anything.

> Step to reproduce: gdb vlc
> output:
> (gdb) run
> Starting program: /usr/bin/vlc
> [Thread debugging using libthread_db enabled]
> Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
> VLC media player 2.2.1 Terry Pratchett (Weatherwax) (revision 2.2.1-0-ga425c42)
> 
> Program received signal SIGSEGV, Segmentation fault.
> __lll_unlock_elision (lock=0x7ffff26d0d08, private=0)
>     at ../sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
> 29      ../sysdeps/unix/sysv/linux/x86/elision-unlock.c: No such file or
> directory.
> (gdb) bt
> #0  __lll_unlock_elision (lock=0x7ffff26d0d08, private=0)
>     at ../sysdeps/unix/sysv/linux/x86/elision-unlock.c:29
> #1  0x00007ffff247f26c in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
> #2  0x00007ffff240fa22 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
> #3  0x00007fffffffd960 in ?? ()
> #4  0x00007ffff2493ea1 in ?? () from /usr/lib/x86_64-linux-gnu/libEGL.so.1
> #5  0x00007fffffffd960 in ?? ()
> #6  0x00007ffff7def59e in _dl_close_worker (map=<optimized out>,
> force=<optimized out>)
>     at dl-close.c:291
> Backtrace stopped: previous frame inner to this frame (corrupt stack?)
> 
> /usr/lib/x86_64-linux-gnu/libEGL.so.1 -> /usr/lib/x86_64-linux-
> gnu/nvidia/libEGL.so.1
> 
> "dmesg|grep pthread" result:
> breetai@mainbak:~$ dmesg |grep pthread
> [73330.105569] traps: vlc[16815] general protection ip:7f47ac388950
> sp:7ffe3908ad98 error:0 in libpthread-2.22.so[7f47ac376000+18000]
> [78860.282876] traps: dolphin[18294] general protection ip:7fc3b0c1b950
> sp:7ffd0a0828d8 error:0 in libpthread-2.22.so[7fc3b0c09000+18000]
> [90812.515421] traps: krunner[20723] general protection ip:7f930fa19950
> sp:7ffc9b5cd988 error:0 in libpthread-2.22.so[7f930fa07000+18000]
> [90826.164341] traps: akonadi_migrati[21161] general protection ip:7f33b7e39950
> sp:7fff9d61bef8 error:0 in libpthread-2.22.so[7f33b7e27000+18000]
> [92621.782318] traps: vlc[21962] general protection ip:7f4241467950
> sp:7ffd8fa98f68 error:0 in libpthread-2.22.so[7f4241455000+18000]
> breetai@mainbak:~$
> 
> 
> installed packages:
> System runs testing.
> 
> libc6:amd64         2.22-0experimental0 from experimental
> nvidia-driver       352.63-1            from experimental
> intel-microcode     3.20151106.1        from testing
> vlc                 2.2.1-5+b1          from testing

Message #92 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Andreas Beckmann <anbe@debian.org>, 800574@bugs.debian.org

Cc: jhaand@xs4all.nl, 807244@bugs.debian.org

Subject: Re: Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)

Date: Tue, 8 Dec 2015 10:23:05 +0100

[Message part 1 (text/plain, inline)]

Hi,

On 2015-12-07 23:26, Andreas Beckmann wrote:
> Dear libc maintainers,
> 
> we recently got a bug report regarding the TSX-NI / lock elision bug in
> combination with the non-free nvidia driver (#807244). Since that is
> supposed to be fixed with the libc in experimental (and now sid as
> well), perhaps you could take a look why this still happens.
> Several forum posts denote that "compiling glibc without
> --enable-lock-elision" works around that issue.

I disagree it is supposed to be fixed. Intel got a few bugs in there
TSX-NI implementation for Haswell and Broadwell and possibly early
versions of Skylake, and to avoid data loss we have therefore disabled
lock elision for some CPU revisions. That said the bugs in the Intel
implementation are corner cases, and it took quite some time for them to
get discovered. If your program crashes reproducibly, it's definitely not
an issue with the TSX-NI implementation. Disabling --enable-lock-elision
it's just a workaround for the real issue. People now start to have CPUs
with a working TSX-NI implementation which is therefore not blacklisted
and thus the problem is appearing again.

> A few ideas from my side, but since I don't have the hardware to test, I
> cannot check anything:
> * that specific CPU needs to be blacklisted / is incorrectly whitelisted

As said above that couldn't be that.

> * nvidia utilizes a code path in libc that is not covered by the current
> patch (and that code path is not used by any other application)
> * nvidia does call something it shouldn't call directly ... thus
> circumenting the runtime-disabling of the specific routines in libc6

According to the backtrace the problem is typical of a call to
mutex_unlock() on a mutex which hasn't been locked with mutex_lock()
before. Nvidia should fix the bug there.

> * nvidia code does issue the problematic instructions itself (but the
> backtrace points to libc, so this sounds unlikely)
> 
> Is there some way to check at runtime how lock elision is handled by
> libc (on a concrete system)?

What do you mean by "how is it handled"? I have attached a small program
which demonstrate the issue. You can use it to check if your system is
using lock elision or not. Running this program with ltrace it's quite
easy the call to an already unlocked mutex. I wonder if it's doable to
do the same with the whole Nvidia stack.

Aurelien

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

[mutex_crash_tsx.c (text/x-csrc, attachment)]

Message #97 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Andreas Beckmann <anbe@debian.org>

To: Aurelien Jarno <aurelien@aurel32.net>, 800574@bugs.debian.org

Cc: jhaand@xs4all.nl, 807244@bugs.debian.org

Subject: Re: Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)

Date: Tue, 08 Dec 2015 19:25:38 +0100

Hi Aurelien,

thanks for your analysis.

On 2015-12-08 10:23, Aurelien Jarno wrote:
> I disagree it is supposed to be fixed. Intel got a few bugs in there
> TSX-NI implementation for Haswell and Broadwell and possibly early
> versions of Skylake, and to avoid data loss we have therefore disabled
> lock elision for some CPU revisions.

That's what I meant with "fixed". But obviously there are two problems
here: buggy hardware (blacklisted, #800574) and ...

> That said the bugs in the Intel
> implementation are corner cases, and it took quite some time for them to
> get discovered. If your program crashes reproducibly, it's definitely not
> an issue with the TSX-NI implementation. Disabling --enable-lock-elision
> it's just a workaround for the real issue. People now start to have CPUs
> with a working TSX-NI implementation which is therefore not blacklisted
> and thus the problem is appearing again.

... buggy software (#807244), which is only exposed by running on
hardware with working TSX-NI.
That could also explain the fact that the bug was introduced in 352+.

Jelle, I didn't dig through the nvidia forums, but if this info isn't
mentioned there already, maybe you could post it:

> According to the backtrace the problem is typical of a call to
> mutex_unlock() on a mutex which hasn't been locked with mutex_lock()
> before.
(or was already unlocked.)


Andreas

Message #102 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Jelle Haandrikman <jhaand@xs4all.nl>

To: Andreas Beckmann <anbe@debian.org>, 800574@bugs.debian.org

Cc: Aurelien Jarno <aurelien@aurel32.net>, 807244@bugs.debian.org

Subject: Re: Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)

Date: Tue, 08 Dec 2015 22:30:10 +0100

Hi Andreas,

On 2015-12-08 19:25, Andreas Beckmann wrote:
> Hi Aurelien,
> 
> ... buggy software (#807244), which is only exposed by running on
> hardware with working TSX-NI.
> That could also explain the fact that the bug was introduced in 352+.
> 
> Jelle, I didn't dig through the nvidia forums, but if this info isn't
> mentioned there already, maybe you could post it:
> 
>> According to the backtrace the problem is typical of a call to
>> mutex_unlock() on a mutex which hasn't been locked with mutex_lock()
>> before.
> (or was already unlocked.)
I'm not a member of any of any Nvidia forum. I'm more of an advanced
Debian user, with a technical background as a tester. All the searches 
that I
just did regarding mutex_unlock() and the driver point back to this 
post.

You really are doing the best anaylysis I had found. Unfortunately it's 
also
the only one I can find.

Thanks for already doing this investigation.

best regards,
Jelle

Message #107 received at 800574@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurelien@aurel32.net>

To: Jelle Haandrikman <jhaand@xs4all.nl>, 800574@bugs.debian.org

Cc: Andreas Beckmann <anbe@debian.org>, 807244@bugs.debian.org

Subject: Re: Bug#800574: Bug#807244: libegl1-nvidia: Programs crash due to elisian-unlock on skylake processor with nvidia driver 352.63-1 (experimental)

Date: Wed, 9 Dec 2015 13:05:59 +0100

On 2015-12-08 22:30, Jelle Haandrikman wrote:
> Hi Andreas,
> 
> On 2015-12-08 19:25, Andreas Beckmann wrote:
> >Hi Aurelien,
> >
> >... buggy software (#807244), which is only exposed by running on
> >hardware with working TSX-NI.
> >That could also explain the fact that the bug was introduced in 352+.
> >
> >Jelle, I didn't dig through the nvidia forums, but if this info isn't
> >mentioned there already, maybe you could post it:
> >
> >>According to the backtrace the problem is typical of a call to
> >>mutex_unlock() on a mutex which hasn't been locked with mutex_lock()
> >>before.
> >(or was already unlocked.)
> I'm not a member of any of any Nvidia forum. I'm more of an advanced
> Debian user, with a technical background as a tester. All the searches that
> I
> just did regarding mutex_unlock() and the driver point back to this post.
> 
> You really are doing the best anaylysis I had found. Unfortunately it's also
> the only one I can find.

As often this can be also found on the archlinux bug tracking system:

https://bugs.archlinux.org/task/46064?project=1

There is even a link to an ugly patch showing that the issue has been
understood. Finally according to the last post in this bug entry it
seems that nvidia is about to release fix.

Aurelien

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

Message #112 received at 800574-close@bugs.debian.org (full text, mbox, reply):

From: Aurelien Jarno <aurel32@debian.org>

To: 800574-close@bugs.debian.org

Subject: Bug#800574: fixed in glibc 2.19-18+deb8u2

Date: Fri, 01 Jan 2016 15:47:08 +0000

Source: glibc
Source-Version: 2.19-18+deb8u2

We believe that the bug you reported is fixed in the latest version of
glibc, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 800574@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Aurelien Jarno <aurel32@debian.org> (supplier of updated glibc package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Mon, 28 Dec 2015 21:39:40 +0100
Source: glibc
Binary: libc-bin libc-dev-bin glibc-doc glibc-source locales locales-all nscd multiarch-support libc6 libc6-dev libc6-dbg libc6-pic libc6-udeb libc6.1 libc6.1-dev libc6.1-dbg libc6.1-pic libc6.1-udeb libc0.3 libc0.3-dev libc0.3-dbg libc0.3-pic libc0.3-udeb libc0.1 libc0.1-dev libc0.1-dbg libc0.1-pic libc0.1-udeb libc6-i386 libc6-dev-i386 libc6-sparc libc6-dev-sparc libc6-sparc64 libc6-dev-sparc64 libc6-s390 libc6-dev-s390 libc6-amd64 libc6-dev-amd64 libc6-powerpc libc6-dev-powerpc libc6-ppc64 libc6-dev-ppc64 libc6-mips32 libc6-dev-mips32 libc6-mipsn32 libc6-dev-mipsn32 libc6-mips64 libc6-dev-mips64 libc0.1-i386 libc0.1-dev-i386 libc6-x32 libc6-dev-x32 libc6-i686 libc6-xen libc0.1-i686 libc0.3-i686 libc0.3-xen libc6.1-alphaev67 libc6-loongson2f libnss-dns-udeb libnss-files-udeb
Architecture: source all
Version: 2.19-18+deb8u2
Distribution: stable
Urgency: medium
Maintainer: Aurelien Jarno <aurel32@debian.org>
Changed-By: Aurelien Jarno <aurel32@debian.org>
Description:
 glibc-doc  - GNU C Library: Documentation
 glibc-source - GNU C Library: sources
 libc-bin   - GNU C Library: Binaries
 libc-dev-bin - GNU C Library: Development binaries
 libc0.1    - GNU C Library: Shared libraries
 libc0.1-dbg - GNU C Library: detached debugging symbols
 libc0.1-dev - GNU C Library: Development Libraries and Header Files
 libc0.1-dev-i386 - GNU C Library: 32bit development libraries for AMD64
 libc0.1-i386 - GNU C Library: 32bit shared libraries for AMD64
 libc0.1-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.1-pic - GNU C Library: PIC archive library
 libc0.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3    - GNU C Library: Shared libraries
 libc0.3-dbg - GNU C Library: detached debugging symbols
 libc0.3-dev - GNU C Library: Development Libraries and Header Files
 libc0.3-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc0.3-pic - GNU C Library: PIC archive library
 libc0.3-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc0.3-xen - GNU C Library: Shared libraries [Xen version]
 libc6      - GNU C Library: Shared libraries
 libc6-amd64 - GNU C Library: 64bit Shared libraries for AMD64
 libc6-dbg  - GNU C Library: detached debugging symbols
 libc6-dev  - GNU C Library: Development Libraries and Header Files
 libc6-dev-amd64 - GNU C Library: 64bit Development Libraries for AMD64
 libc6-dev-i386 - GNU C Library: 32-bit development libraries for AMD64
 libc6-dev-mips32 - GNU C Library: o32 Development Libraries for MIPS
 libc6-dev-mips64 - GNU C Library: 64bit Development Libraries for MIPS64
 libc6-dev-mipsn32 - GNU C Library: n32 Development Libraries for MIPS64
 libc6-dev-powerpc - GNU C Library: 32bit powerpc development libraries for ppc64
 libc6-dev-ppc64 - GNU C Library: 64bit Development Libraries for PowerPC64
 libc6-dev-s390 - GNU C Library: 32bit Development Libraries for IBM zSeries
 libc6-dev-sparc - GNU C Library: 32bit Development Libraries for SPARC
 libc6-dev-sparc64 - GNU C Library: 64bit Development Libraries for UltraSPARC
 libc6-dev-x32 - GNU C Library: X32 ABI Development Libraries for AMD64
 libc6-i386 - GNU C Library: 32-bit shared libraries for AMD64
 libc6-i686 - GNU C Library: Shared libraries [i686 optimized]
 libc6-loongson2f - GNU C Library: Shared libraries (Loongson 2F optimized)
 libc6-mips32 - GNU C Library: o32 Shared libraries for MIPS
 libc6-mips64 - GNU C Library: 64bit Shared libraries for MIPS64
 libc6-mipsn32 - GNU C Library: n32 Shared libraries for MIPS64
 libc6-pic  - GNU C Library: PIC archive library
 libc6-powerpc - GNU C Library: 32bit powerpc shared libraries for ppc64
 libc6-ppc64 - GNU C Library: 64bit Shared libraries for PowerPC64
 libc6-s390 - GNU C Library: 32bit Shared libraries for IBM zSeries
 libc6-sparc - GNU C Library: 32bit Shared libraries for SPARC
 libc6-sparc64 - GNU C Library: 64bit Shared libraries for UltraSPARC
 libc6-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libc6-x32  - GNU C Library: X32 ABI Shared libraries for AMD64
 libc6-xen  - GNU C Library: Shared libraries [Xen version]
 libc6.1    - GNU C Library: Shared libraries
 libc6.1-alphaev67 - GNU C Library: Shared libraries (EV67 optimized)
 libc6.1-dbg - GNU C Library: detached debugging symbols
 libc6.1-dev - GNU C Library: Development Libraries and Header Files
 libc6.1-pic - GNU C Library: PIC archive library
 libc6.1-udeb - GNU C Library: Shared libraries - udeb (udeb)
 libnss-dns-udeb - GNU C Library: NSS helper for DNS - udeb (udeb)
 libnss-files-udeb - GNU C Library: NSS helper for files - udeb (udeb)
 locales    - GNU C Library: National Language (locale) data [support]
 locales-all - GNU C Library: Precompiled locale data
 multiarch-support - Transitional package to ensure multiarch compatibility
 nscd       - GNU C Library: Name Service Cache Daemon
Closes: 779587 798316 798515 799966 800523 800574 801691 802256 803927
Changes:
 glibc (2.19-18+deb8u2) stable; urgency=medium
 .
   [ Aurelien Jarno ]
   * Update from upstream stable branch:
     - Fix getaddrinfo sometimes returning uninitialized data with nscd.
       Closes: #798515.
     - Fix data corruption while reading the NSS files database
       (CVE-2015-5277).  Closes: #799966.
     - Fix buffer overflow (read past end of buffer) in internal_fnmatch.
     - Fix  _IO_wstr_overflow integer overflow.
     - Fix unexpected closing of nss_files databases after lookups,
       causing denial of service (CVE-2014-8121).  Closes: #779587.
     - Fix NSCD netgroup cache.  Closes: #800523.
   * patches/any/cvs-ld_pointer_guard.diff: new patch from upstream to
     unconditionally disable LD_POINTER_GUARD.  Closes: #798316, #801691.
   * patches/any/cvs-mangle-tls_dtor_list.diff: new patch from upstream to
     mangle function pointers in tls_dtor_list.  Closes: #802256.
   * patches/any/cvs-strxfrm-buffer-overflows.diff: new patch from upstream
     to fix memory allocations issues that can lead to buffer overflows on
     the stack.  Closes: #803927.
 .
   [ Henrique de Moraes Holschuh ]
   * Replace patches/amd64/local-blacklist-on-TSX-Haswell.diff by
     local-blacklist-for-Intel-TSX.diff also blacklisting some Broadwell
     models.  Closes: #800574.
Checksums-Sha1:
 e4386b9b316fb3366323a25c5626df580b3dd100 8236 glibc_2.19-18+deb8u2.dsc
 9a766804327f12ab4424afab959c97d930421f1a 1040948 glibc_2.19-18+deb8u2.debian.tar.xz
 bbf48a19e71e8c9367d8514ff2e1131d34f0134e 2267136 glibc-doc_2.19-18+deb8u2_all.deb
 35528d07531cc05b48fe0a3405de48e2ab91491b 13976542 glibc-source_2.19-18+deb8u2_all.deb
 0b0f9e53d313deb1965e7994c386b5384be66bc2 3954372 locales_2.19-18+deb8u2_all.deb
Checksums-Sha256:
 f87e7448c2e460aac9b1a420469b7848b057a5d4e9f716b26d0277446eabac13 8236 glibc_2.19-18+deb8u2.dsc
 0e407d1610ba95adfe641d7030ddac13105682f638cf8ff1286dfd1c44d24aa3 1040948 glibc_2.19-18+deb8u2.debian.tar.xz
 24366700536fe92feb1570b5ce733d09fac4d1956a5904e330ad7bb642a2a167 2267136 glibc-doc_2.19-18+deb8u2_all.deb
 b940f7c54a40513b5915ff6534b89d5f6b2154c2e78980bfe37b08264f55f90d 13976542 glibc-source_2.19-18+deb8u2_all.deb
 e7694d8bfafffbf78b3ebb79f9e3218d699f0e13b761e1f4c7848705eebc9fe2 3954372 locales_2.19-18+deb8u2_all.deb
Files:
 645a3775c11f5c216a25683b37db0f80 8236 libs required glibc_2.19-18+deb8u2.dsc
 f7c75b3bdf661a84abf51420f15b6933 1040948 libs required glibc_2.19-18+deb8u2.debian.tar.xz
 80e5c2d6537a71b13c549f628e2fdf71 2267136 doc optional glibc-doc_2.19-18+deb8u2_all.deb
 fa2a8d49a5d97782a4f17aaea6edb642 13976542 devel optional glibc-source_2.19-18+deb8u2_all.deb
 f3090452ea4d882d1891f265b90a5979 3954372 localization standard locales_2.19-18+deb8u2_all.deb
Package-Type: udeb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBAgAGBQJWgb0OAAoJELqceAYd3Yyb8FcP/3FJ4wWofgVMLI/u8Po9Iq2e
s3YRCwQNyCR7yGPiQS4Ow5OX3z/McXAG9MptMrWJUPetlFYttMqJJ7oW6Sgx5gZq
oZqbU2bI3pvH3qzy/VJfhJSD9r9qYoDRg+5N1LJtpF8D42CbEnKZDNT0KEAFo2qB
5lQcesVhfOGJt8GywiI8W+E10qSaAioWE/qD+D5QSpzoO25suB+9b8spGRZKIT/9
5B36o0DZFfcooPWjjkzab245TKu4SSSmC721whR2HcS4u3mcx9ZdqTEpsEk0DNWm
Hq25r0UJ8nvBffrgBY23odYRWgWeSNQcVml07RFY0dkNyz6FaX1x0917wnBzLvgX
0QAM+gSNs07e6QQV1AnrGzpXRUXsD3KTVklMrkKrKlZ0qmVZjKwzIm3COrIdEXUD
2FU/nSO49zLAvH+kUGMSeDQRDg4pgG2A/uhIq+ty8oBzkDiQvOpZNO8XZ8x2f43O
g1l/RcUF46yzu3WJjKOGoyukKvLMnhywppTHkD4S7fVL+p1mtpBr6p+lNQ9wZuHk
lxYJH4VcmcN1r2mEG6NcR8vdnSWueFIANaFRb/gSiz+oFo0inGLVFgC82a7moD05
yKXLR5BQo5fBNu0upLIrPHK1td9+bAaCyl2O5KlER2YzLtEqVJWcj2J5W/8itYaV
3XIC0DPL18g5+v9LXDpC
=+T4w
-----END PGP SIGNATURE-----

Send a report that this bug log contains spam.