Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 02 Nov 2023 00:28:59 +0700
From: Alexey Izbyshev <>
Subject: Re: synccall patches

On 2023-11-01 20:00, Rich Felker wrote:
> On Tue, Oct 31, 2023 at 05:21:01PM +0100, Markus Wichmann wrote:
>> 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.
> I think your assessment of the problem is correct and I think your fix
> works but I need to look at it in a little more detail. Review from
> others familiar with this stuff would be very welcome too.
I looked at synccall code back when it was rewritten in commit 
e4235d70672d9751d7718ddc2b52d0b426430768, but I missed this bug. Markus' 
patch looks good to me.


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.