[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <2193f3bd74f006d5bd44ecf5af6187fa@ispras.ru>
Date: Thu, 02 Nov 2023 00:28:59 +0700
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: musl@...ts.openwall.com
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.
Alexey
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.
