https://sourceware.org/bugzilla/show_bug.cgi?id=33382
Bug ID: 33382
Summary: Investigate unlock/wrlock pattern
Product: elfutils
Version: unspecified
Status: NEW
Severity: normal
Priority: P2
Component: general
Assignee: unassigned at sourceware dot org
Reporter: mark at klomp dot org
CC: elfutils-devel at sourceware dot org
Target Milestone: ---
There are various unlock/rwlock patterns in the code where a read lock has been
taken, a condition is detected that needs writing to the datastructure, the
read lock is dropped and the write lock is acquired.
This might be OK if the condition is rechecked after acquiring the write lock
to make sure there wasn't another thread racing past the unlock and relock that
changed the data structures. But this doesn't always happen, see e.g.
elf_getdata_rawchunk.c: Fix dummy chunk insertion race condition
https://patchwork.sourceware.org/project/elfutils/patch/20250904182432.1618673-1-ame...@redhat.com/
We should audit this pattern and make sure the code contains comments why it is
correct:
- libdw/libdw_alloc.c (__libdw_alloc_tail)
Looks correct, condition is rechecked
- libelf/elf32_getehdr.c (getehdr_impl)
Might be correct, goto again which rechecks condition
- libelf/elf32_getshdr.c (getshdr_rdlock)
Does reload result and rechecks.
- libelf/elf_begin.c (lock_dup_elf)
Looks racy. But depends on caller and what the called dup_elf does.
- libelf/elf_getdata.c (__libelf_set_data_list_rdlock):
Looks OK. Rechecks condition.
(__elf_getdata_rdlock):
Comment says it is OK, but I don't get it.
- libelf/elf_strptr.c (elf_strptr):
Looks correct, condition is rechecked.
Random other observation:
- dwflst_process_tracker.c (dwflst_tracker_end)
/* HACK to allow iteration of dynamicsizehash_concurrent. */
/* XXX Based on lib/dynamicsizehash_concurrent.c free(). */
Investigate.
--
You are receiving this mail because:
You are on the CC list for the bug.
