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.