[Bug nptl/17351] New: No hardware with functional lock elision available

[Bug nptl/17351] New: No hardware with functional lock elision available

[cedric.bail at free dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=17351

            Bug ID: 17351
           Summary: No hardware with functional lock elision available
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: normal
          Priority: P2
         Component: nptl
          Assignee: unassigned at sourceware dot org
          Reporter: cedric.bail at free dot fr
                CC: drepper.fsp at gmail dot com

Intel has found an issue in the lock elision micro code and is rolling out a
microcode that disable it apparently for older haswell.

http://techreport.com/news/26911/errata-prompts-intel-to-disable-tsx-in-haswell-early-broadwell-cpus
http://anandtech.com/show/8376/intel-disables-tsx-instructions-erratum-found-in-haswell-haswelleep-broadwell
http://www.intel.com/content/dam/www/public/us/en/documents/specification-updates/xeon-e3-1200v3-spec-update.pdf

People who did not update their microcode will have some weird/random issue
most likely when using a glibc build with elision. Arch Linux has concluded it
is not a software bug and it doesn't require to change their packaging
(https://bugs.archlinux.org/task/39631).

Please advise what is the proper solution to this problem, as it potentially
affect a lot of people who wont know where the problem come from.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17351] No hardware with functional lock elision available

[cedric.bail at free dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=17351

--- Comment #2 from Cedric BAIL <cedric.bail at free dot fr> ---
Did you choose to force the microcode update on Redhat ? If not how do you
advise  user who have random crash and have absolutely no clue where to look ?

I don't know if you know, but rust has build a work around this bug to prevent
bug from happening on software build with it :
https://github.com/rocallahan/rr/commit/d389eb724a9b5f895f813600d9276e00dc063068
.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17351] No hardware with functional lock elision available

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17351

--- Comment #3 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Cedric BAIL from comment #2)
> Did you choose to force the microcode update on Redhat ? If not how do you
> advise  user who have random crash and have absolutely no clue where to look
> ?

Please contact Red Hat support for an answer to this question.

No RHEL glibc enables lock elision.

> I don't know if you know, but rust has build a work around this bug to
> prevent bug from happening on software build with it :
> https://github.com/rocallahan/rr/commit/
> d389eb724a9b5f895f813600d9276e00dc063068 .

That isn't a workaround for the errata.

Rust is disabling elision in glibc for their own reasons, it isn't disabling
elision in general. Other applications will continue to check the cpuid RTM bit
and use elision.

You as a user must make an informed choice to update or not update the
microcode for the errata issue.

And Fedora glibc will continue to support those users that wish to use RTM on
those CPUs.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17351] No hardware with functional lock elision available

[cedric.bail at free dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=17351

--- Comment #4 from Cedric BAIL <cedric.bail at free dot fr> ---
Checking the CPU RTM bit is not enough for application, they also need to check
the microcode version (This is the reason why glibc is turning on elision when
it should not use it in my opinion).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17351] No hardware with functional lock elision available

[carlos at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=17351

--- Comment #5 from Carlos O'Donell <carlos at redhat dot com> ---
(In reply to Cedric BAIL from comment #4)
> Checking the CPU RTM bit is not enough for application, they also need to
> check the microcode version (This is the reason why glibc is turning on
> elision when it should not use it in my opinion).

You misunderstand. We will not protect you from faulty hardware. The choice is
up to the user to apply the microcode update or not. It is *after* the
microcode update that the RTM-enabled CPU with errata will have the RTM bit
disabled, and therefore glibc will not use elision. On RTM-enabled CPUs that
don't have the errata the RTM bit will be enabled and glibc will use elision.
The library will not attempt to check the microcode version to disable elision,
that is the responsibility of the user. All I was clarifying was that after the
microcode update the library does the right thing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug nptl/17351] No hardware with functional lock elision available

[cedric.bail at free dot fr]

https://sourceware.org/bugzilla/show_bug.cgi?id=17351

--- Comment #6 from Cedric BAIL <cedric.bail at free dot fr> ---
Oh, I see ! Well, I guess I should consider protecting the user of my library
by inserting the same hack that will turn of elision. It will reduce the
potential instability they face and wont hurt at all as their is no hardware
where this work.

Thanks for your help explaining glibc position.

-- 
You are receiving this mail because:
You are on the CC list for the bug.