diff options
author | Rich Felker <dalias@aerifal.cx> | 2019-02-12 19:56:49 -0500 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2019-02-12 19:56:49 -0500 |
commit | 099b89d3840c30d7dd962e18668c2e6d39f0c626 (patch) | |
tree | eba766cb65c04a65be534979394b6f7eeb6b6b1e /src/stdio | |
parent | 042b3ee452f542e0e16d847f90777e8c3a012375 (diff) | |
download | musl-099b89d3840c30d7dd962e18668c2e6d39f0c626.tar.gz musl-099b89d3840c30d7dd962e18668c2e6d39f0c626.tar.bz2 musl-099b89d3840c30d7dd962e18668c2e6d39f0c626.tar.xz musl-099b89d3840c30d7dd962e18668c2e6d39f0c626.zip |
redesign robust mutex states to eliminate data races on type field
in order to implement ENOTRECOVERABLE, the implementation has
traditionally used a bit of the mutex type field to indicate that it's
recovered after EOWNERDEAD and will go into ENOTRECOVERABLE state if
pthread_mutex_consistent is not called before unlocking. while it's
only the thread that holds the lock that needs access to this
information (except possibly for the sake of pthread_mutex_consistent
choosing between EINVAL and EPERM for erroneous calls), the change to
the type field is formally a data race with all other threads that
perform any operation on the mutex. no individual bits race, and no
write races are possible, so things are "okay" in some sense, but it's
still not good.
this patch moves the recovery/consistency state to the mutex
owner/lock field which is rightfully mutable. bit 30, the same bit the
kernel uses with a zero owner to indicate that the previous owner died
holding the lock, is now used with a nonzero owner to indicate that
the mutex is held but has not yet been marked consistent. note that
the kernel ABI also reserves bit 29 not to appear in any tid, so the
sentinel value we use for ENOTRECOVERABLE, 0x7fffffff, does not clash
with any tid plus bit 30.
Diffstat (limited to 'src/stdio')
0 files changed, 0 insertions, 0 deletions