From Fedora Project Wiki
(https://pagure.io/fesco/issue/1870)
No edit summary
 
Line 51: Line 51:
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
CLOSED as NEXTRELEASE -> change is completed and verified and will be delivered in next release under development
-->
-->
* Tracker bug: <will be assigned by the Wrangler>
* Tracker bug: [https://bugzilla.redhat.com/show_bug.cgi?id=1565025 #1565025]
* Release Notes tracking: [https://pagure.io/fedora-docs/release-notes/issue/135 #135]


== Detailed Description ==
== Detailed Description ==
Line 157: Line 158:
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
Release Notes are not required for initial draft of the Change Proposal but has to be completed by the Change Freeze.  
-->
-->
* Release Notes tracking: [https://pagure.io/fedora-docs/release-notes/issue/135 #135]


[[Category:ChangeReadyForFesco]]
[[Category:ChangeAcceptedF28]]
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- When your change proposal page is completed and ready for review and announcement -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->
<!-- remove Category:ChangePageIncomplete and change it to Category:ChangeReadyForWrangler -->

Latest revision as of 07:45, 9 April 2018


Stop building 389-ds-base on i686

Summary

389-ds-base does not work properly on i686 hardware in regards to atomic types.

Owner

  • Name: Mark Reynolds
  • Email: mreynolds@redhat.com
  • Release notes owner:
  • Product: 389-ds-base. FreeIPA, slapi-nis
  • Responsible WG:


Current status

Detailed Description

389-ds project have found an issue which causes system instability on all versions of 1.4.x of the server on i686 platform. This is a hardware limitation of the platform related to how we consume atomic types. Our testing has shown that in i686 the atomic counters can have unpredictable values/behaviour. We use atomic counters all over the code base, and it many critical objects. This may lead to thread unsafety and other serious issues.

There is more detail in this bug: https://bugzilla.redhat.com/show_bug.cgi?id=1544386

Here is a bug snippet from the engineer who originally found the problem and did the all the investigation work (who is also not at Red Hat any more):


In libc there are a number of __atomic_* types that promise that "They perform atomic manipulations of the data, falling back to a mutex in the case that a native cpu atomic can not be used". On 32bit platforms this fallback does *not* occur correctly, meaning that either the lower or upper half only is atomically updated. This is due to variable alignment not being correctly emited by gcc, meaning we would have to then align every data that uses this.

This was discovered due to expansion of our testing capability of the C code base - a server stress test showed that counters could become wildly inaccurate.

Given we use atomics for reference counting in a number of objects, as well as for monitors, this can cause objects to leak, be freed early, or to report incorrect data...


Also impacted:

 - FreeIPA server will not be available on i686 due to this
 - slapi-nis set of plugins will not be available on i686 due to this
 - Upgrade of i686 instance of Fedora with FreeIPA server will not be possible without fully uninstalling FreeIPA replica

Benefit to Fedora

Stable release of 389-ds-base, FreeIPA, and slapi-nis on remaining architectures

Scope

  • Proposal owners:

This only requires a change to spec file to exclude i686

  • Other developers: N/A (not a System Wide Change)
  • Policies and guidelines: N/A (not a System Wide Change)
  • Trademark approval: N/A (not needed for this Change)

Upgrade/compatibility impact

N/A (not a System Wide Change)

How To Test

Nothing to test except making sure there is no i686 builds present on f28

N/A (not a System Wide Change)

User Experience

N/A (not a System Wide Change)

Dependencies

N/A (not a System Wide Change)

Contingency Plan

  • Contingency mechanism: (What to do? Who will do it?) N/A (not a System Wide Change)
  • Contingency deadline: N/A (not a System Wide Change)
  • Blocks release? N/A (not a System Wide Change), Yes/No
  • Blocks product? product

Somehow flag the build as unstable, use at your own risk.

Documentation

N/A (not a System Wide Change)

Release Notes

  • Release Notes tracking: #135