[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <d835d7c05087d226fd6cfaee512a7783@ispras.ru>
Date: Wed, 09 Sep 2026 13:58:34 +0300
From: Alexey Izbyshev <izbyshev@...ras.ru>
To: musl@...ts.openwall.com
Subject: Re: Fix deadlock in timer_create when syscall fails
On 2026-09-08 23:56, Colin Cross wrote:
> On Sun, Sep 6, 2026 at 11:57 AM Alexey Izbyshev <izbyshev@...ras.ru>
> wrote:
>>
>> On 2026-09-03 10:00, Szabolcs Nagy wrote:
>> >
>> > it seems
>> >
>> > commit 3ad3fa962efee12067d68c3405a537dce156a7ac
>> > fix thread leak on timer_create(SIGEV_THREAD) failure
>> >
>> > (ab)used self->cancel to mark timer_create failures, because
>> > the obvious self->timer_id < 0 can also mean deleted timer.
>> > then
>> >
>> > commit cde213f9c3ac1aa168581222edee6a6642113323
>> > timer_create: replace pthread barrier with semaphores for thread
>> > start
>> >
>> > changed the sync to two sems, introducing the cancel deadlock,
>>
>> and other issues:
>> * sem_wait call now clobbers errno set by timer_create.
>> * if sem_wait is cancelled, the timer and its thread are leaked, and
>> the
>> thread may also access args past its lifetime.
>
> I've attached v3 that fixes these two issues as well by disabling
> cancellation around the semaphore operations in the parent thread and
> saving the return value of SYS_timer_create.
The logic of the patch looks good to me. One possible nit is that plain
(no double-underscores) pthread_setcancelstate should be fine here,
since timer_create is not in standard C, hence no namespace issues.
Thanks,
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.
