group.of.nepali.translators team mailing list archive

[Adam Conrad <adconrad@xxxxxxx>]

Public bug reported:

[ SRU Justification ]
A long thread on debian-devel[1] has pointed out that hardware lock elision behaves differently (arguably, more correctly) in the face of incorrect pthread usage, especially where double-unlocks are concerned.  While this isn't itself a bug, it's quite true that we have no way of knowing right now just how many third party sources are buggy, and as people are upgrading to hardware that supports this feature, more software may crash in the future.

The long-term goal should be to try to ferret out all the bad actors
here, fix them, and re-enable hardware lock elision as the default, but
the sane conservative choice seems to be to just disable the feature
entirely for now, while we (the glibc upstream community) work on making
lock elision a per-process opt-in.

[1] https://lists.debian.org/debian-devel/2016/11/msg00210.html

[ Proposed Fix ]
This SRU will disable lock elision entirely, thus avoiding the problematic codepaths.  A future SRU will re-enable building those codepaths, but in such a way that they're disabled by default with a per-process environment twiddle to enable it on demand.

[ Regression Potential ]
There's a potential for performance regressions, however given that most x86 users are only just now upgrading to hardware that supports this feature, the status quo is that this codepath is dead to most users.  As for s390x and PPC, we've had requests to disable lock elision by default on both arches (entirely on s390x, conditionally on PPC), and those requests will be somewhat satisfied by this SRU, and cleaned up in the future SRU where we integrate the upstream-concensus patch to allow it to be conditionally re-enabled.

[ Testing ]
autopkgtest regressions will be our guide here on if this SRU is causing any issues.

** Affects: glibc (Ubuntu)
     Importance: Undecided
     Assignee: Adam Conrad (adconrad)
         Status: New

** Affects: glibc (Ubuntu Xenial)
     Importance: Undecided
     Assignee: Adam Conrad (adconrad)
         Status: New

** Affects: glibc (Ubuntu Yakkety)
     Importance: Undecided
     Assignee: Adam Conrad (adconrad)
         Status: New

** Also affects: glibc (Ubuntu Xenial)
   Importance: Undecided
       Status: New

** Also affects: glibc (Ubuntu Yakkety)
   Importance: Undecided
       Status: New

-- 
You received this bug notification because you are a member of नेपाली
भाषा समायोजकहरुको समूह, which is subscribed to Xenial.
Matching subscriptions: Ubuntu 16.04 Bugs
https://bugs.launchpad.net/bugs/1642390

Title:
  Disable lock-elision in glibc pending upstream changes

Status in glibc package in Ubuntu:
  New
Status in glibc source package in Xenial:
  New
Status in glibc source package in Yakkety:
  New

Bug description:
  [ SRU Justification ]
  A long thread on debian-devel[1] has pointed out that hardware lock elision behaves differently (arguably, more correctly) in the face of incorrect pthread usage, especially where double-unlocks are concerned.  While this isn't itself a bug, it's quite true that we have no way of knowing right now just how many third party sources are buggy, and as people are upgrading to hardware that supports this feature, more software may crash in the future.

  The long-term goal should be to try to ferret out all the bad actors
  here, fix them, and re-enable hardware lock elision as the default,
  but the sane conservative choice seems to be to just disable the
  feature entirely for now, while we (the glibc upstream community) work
  on making lock elision a per-process opt-in.

  [1] https://lists.debian.org/debian-devel/2016/11/msg00210.html

  [ Proposed Fix ]
  This SRU will disable lock elision entirely, thus avoiding the problematic codepaths.  A future SRU will re-enable building those codepaths, but in such a way that they're disabled by default with a per-process environment twiddle to enable it on demand.

  [ Regression Potential ]
  There's a potential for performance regressions, however given that most x86 users are only just now upgrading to hardware that supports this feature, the status quo is that this codepath is dead to most users.  As for s390x and PPC, we've had requests to disable lock elision by default on both arches (entirely on s390x, conditionally on PPC), and those requests will be somewhat satisfied by this SRU, and cleaned up in the future SRU where we integrate the upstream-concensus patch to allow it to be conditionally re-enabled.

  [ Testing ]
  autopkgtest regressions will be our guide here on if this SRU is causing any issues.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/glibc/+bug/1642390/+subscriptions