Re: [musl] synccall patches

[Alexey Izbyshev <izbyshev@ispras.ru>]

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