summaryrefslogtreecommitdiff
path: root/src/stdio
diff options
context:
space:
mode:
authorRich Felker <dalias@aerifal.cx>2019-02-12 19:56:49 -0500
committerRich Felker <dalias@aerifal.cx>2019-02-12 19:56:49 -0500
commit099b89d3840c30d7dd962e18668c2e6d39f0c626 (patch)
treeeba766cb65c04a65be534979394b6f7eeb6b6b1e /src/stdio
parent042b3ee452f542e0e16d847f90777e8c3a012375 (diff)
downloadmusl-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