[Bug dynamic-link/28745] _dl_find_object miscompilation on powerpc64le

fweimer at redhat dot com sourceware-bugzilla@sourceware.org
Fri Jan 7 12:23:03 GMT 2022


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

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
   Target Milestone|---                         |2.35
             Status|NEW                         |RESOLVED

--- Comment #4 from Florian Weimer <fweimer at redhat dot com> ---
Fixed via:

commit acbaad31e8ea10fce8b9c0aef58afb388bf7489d
Author: Florian Weimer <fweimer@redhat.com>
Date:   Fri Jan 7 13:21:57 2022 +0100

    elf: Fix fences in _dl_find_object_update (bug 28745)

    As explained in Hans Boehm, Can Seqlocks Get Along with Programming
    Language Memory Models?, an acquire fence is needed in
    _dlfo_read_success.  The lack of a fence resulted in an observable
    bug on powerpc64le compile-time load reordering.

    The fence in _dlfo_mappings_begin_update has been reordered, turning
    the fence/store sequence into a release MO store equivalent.

    Relaxed MO loads are used on the reader side, and relaxed MO stores
    on the writer side for the shared data, to avoid formal data races.
    This is just to be conservative; it should not actually be necessary
    given how the data is used.

    This commit also fixes the test run time.  The intent was to run it
    for 3 seconds, but 0.3 seconds was enough to uncover the bug very
    occasionally (while 3 seconds did not reliably show the bug on every
    test run).

    Reviewed-by: Szabolcs Nagy <szabolcs.nagy@arm.com>

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


More information about the Glibc-bugs mailing list