about summary refs log tree commit diff
path: root/src/stdio/putchar_unlocked.c
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/putchar_unlocked.c
parent042b3ee452f542e0e16d847f90777e8c3a012375 (diff)
downloadmusl-099b89d3840c30d7dd962e18668c2e6d39f0c626.tar.gz
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/putchar_unlocked.c')
0 files changed, 0 insertions, 0 deletions