[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <ZUEpbaMgWrtBTCqb@voyager>
Date: Tue, 31 Oct 2023 17:21:01 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: synccall patches
Hi all,
fittingly for Reformation Day, I chose to actually send in some patches
today, rather than provide comments. And fittingly for Halloween, they
concern a scary part of musl, namely __synccall().
First I noticed that the initial return value set in __setxid() is not a
valid return value for the functions that call it. Those are only
allowed to return 0 or -1, not 1. That is easily fixed.
Then I noticed that __synccall() has a logic bug explained in the commit
message. It wouldn't be a bug if semaphores had any kind of preference
for the thread that has waited longest or something, but musl does not
implement something like this. And the kernel explicitly documents that
FUTEX_WAKE will wake a random thread.
At first I thought the best solution would be to forego the serialized
execution of the callback; just release all threads in line 97 (and then
fix the callbacks to cope with parallel execution). But BSD semaphores
have no way to do that, and a mass-release loop like the one on line 110
would have the same issue as given here. It would only be less likely to
happen, with the likelihood rising with the number of threads. So a new
semaphore it is.
Ciao,
Markus
View attachment "0001-Initialize-setxid-retval-to-valid-value.patch" of type "text/x-diff" (1347 bytes)
View attachment "0002-synccall-Add-exit_sem.patch" of type "text/x-diff" (2399 bytes)
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
