glibc:nsz/bug19329

Last commit made on 2021-02-15
Get this branch:
git clone -b nsz/bug19329 https://git.launchpad.net/glibc

Branch merges

Branch information

Name:
nsz/bug19329
Repository:
lp:glibc

Recent commits

191f5ae... by Szabolcs Nagy <email address hidden> on 2021-02-11

elf: Remove lazy tlsdesc relocation related code

Remove generic tlsdesc code related to lazy tlsdesc processing since
lazy tlsdesc relocation is no longer supported. This includes removing
GL(dl_load_lock) from _dl_make_tlsdesc_dynamic which is only called at
load time when that lock is already held.

Added a documentation comment too.

14e2476... by Szabolcs Nagy <email address hidden> on 2021-02-11

i386: Remove lazy tlsdesc relocation related code

Like in commit e75711ebfa976d5468ec292282566a18b07e4d67 for x86_64,
remove unused lazy tlsdesc relocation processing code:

  _dl_tlsdesc_resolve_abs_plus_addend
  _dl_tlsdesc_resolve_rel
  _dl_tlsdesc_resolve_rela
  _dl_tlsdesc_resolve_hold

fb33cc1... by Szabolcs Nagy <email address hidden> on 2021-02-11

x86_64: Remove lazy tlsdesc relocation related code

_dl_tlsdesc_resolve_rela and _dl_tlsdesc_resolve_hold are only used for
lazy tlsdesc relocation processing which is no longer supported.

8d0dcd9... by Szabolcs Nagy <email address hidden> on 2021-02-11

i386: Avoid lazy relocation of tlsdesc [BZ #27137]

Lazy tlsdesc relocation is racy because the static tls optimization and
tlsdesc management operations are done without holding the dlopen lock.

This similar to the commit b7cf203b5c17dd6d9878537d41e0c7cc3d270a67
for aarch64, but it fixes a different race: bug 27137.

On i386 the code is a bit more complicated than on x86_64 because both
rel and rela relocs are supported.

9fc1e41... by Szabolcs Nagy <email address hidden> on 2021-02-11

x86_64: Avoid lazy relocation of tlsdesc [BZ #27137]

Lazy tlsdesc relocation is racy because the static tls optimization and
tlsdesc management operations are done without holding the dlopen lock.

This similar to the commit b7cf203b5c17dd6d9878537d41e0c7cc3d270a67
for aarch64, but it fixes a different race: bug 27137.

c620812... by Szabolcs Nagy <email address hidden> on 2020-12-31

elf: Fix DTV gap reuse logic [BZ #27135]

For some reason only dlopen failure caused dtv gaps to be reused.

It is possible that the intent was to never reuse modids for a
different module, but after dlopen failure all gaps are reused
not just the ones caused by the unfinished dlopened.

So the code has to handle reused modids already which seems to
work, however the data races at thread creation and tls access
(see bug 19329 and bug 27111) may be more severe if slots are
reused so this is scheduled after those fixes. I think fixing
the races are not simpler if reuse is disallowed and reuse has
other benefits, so set GL(dl_tls_dtv_gaps) whenever entries are
removed from the middle of the slotinfo list. The value does
not have to be correct: incorrect true value causes the next
modid query to do a slotinfo walk, incorrect false will leave
gaps and new entries are added at the end.

Fixes bug 27135.

b366056... by Szabolcs Nagy <email address hidden> on 2020-12-30

elf: Use relaxed atomics for racy accesses [BZ #19329]

This is a follow up patch to the fix for bug 19329. This adds
relaxed MO atomics to accesses that are racy, but relaxed MO is
enough.

b64e14f... by Szabolcs Nagy <email address hidden> on 2020-12-30

elf: Fix data races in pthread_create and TLS access [BZ #19329]

DTV setup at thread creation (_dl_allocate_tls_init) is changed
to take the dlopen lock, GL(dl_load_lock). Avoiding data races
here without locks would require design changes: the map that is
accessed for static TLS initialization here may be concurrently
freed by dlclose. That use after free may be solved by only
locking around static TLS setup or by ensuring dlclose does not
free modules with static TLS, however currently every link map
with TLS has to be accessed at least to see if it needs static
TLS. And even if that's solved, still a lot of atomics would be
needed to synchronize DTV related globals without a lock. So fix
both bug 19329 and bug 27111 with a lock that prevents DTV setup
running concurrently with dlopen or dlclose.

_dl_update_slotinfo at TLS access still does not use any locks
so CONCURRENCY NOTES are added to explain the synchronization.
The early exit from the slotinfo walk when max_modid is reached
is not strictly necessary, but does not hurt either.

An incorrect acquire load was removed from _dl_resize_dtv: it
did not synchronize with any release store or fence and
synchronization is now handled separately at thread creation
and TLS access time.

There are still a number of racy read accesses to globals that
will be changed to relaxed MO atomics in a followup patch. This
should not introduce regressions compared to existing behaviour
and avoid cluttering the main part of the fix.

Not all TLS access related data races got fixed here: there are
additional races at lazy tlsdesc relocations see bug 27137.

35ca471... by Szabolcs Nagy <email address hidden> on 2020-12-30

elf: Refactor _dl_update_slotinfo to avoid use after free

map is not valid to access here because it can be freed by a
concurrent dlclose, so don't check the modid.

The map == 0 and map != 0 code paths can be shared (avoiding
the dtv resize in case of map == 0 is just an optimization:
larger dtv than necessary would be fine too).

c54c412... by Szabolcs Nagy <email address hidden> on 2016-11-30

elf: Fix comments and logic in _dl_add_to_slotinfo

Since

  commit a509eb117fac1d764b15eba64993f4bdb63d7f3c
  Avoid late dlopen failure due to scope, TLS slotinfo updates [BZ #25112]

the generation counter update is not needed in the failure path.