[Xenomai] Deadlock in CANCEL_RESTORE with CONFIG_XENO_ASYNC_CANCEL during thread suspension

Philippe Gerum rpm at xenomai.org
Mon Apr 21 12:48:36 CEST 2014


On 04/16/2014 08:34 PM, Matthias Schneider wrote:
> ----- Original Message -----
>
>> From: Philippe Gerum <rpm at xenomai.org>
>> To: Matthias Schneider <ma30002000 at yahoo.de>; "xenomai at xenomai.org" <xenomai at xenomai.org>
>> Cc:
>> Sent: Monday, April 7, 2014 11:59 AM
>> Subject: Re: [Xenomai] Deadlock in CANCEL_RESTORE with CONFIG_XENO_ASYNC_CANCEL during thread suspension
>>
>> On 04/06/2014 01:50 PM, Matthias Schneider wrote:
>>>   Hi all,
>>>
>>>   using xenomai-forge with mercury, when
>>>   CONFIG_XENO_ASYNC_CANCEL is defined, CANCEL_RESTORE
>>>   will include a call to backtrace_check(), which in turn
>>>   will call backtrace_dump, which will take the
>>>   mutex "__printlock".
>>>
>>>   In case a thread gets suspended while holding that lock,
>>>   the next call to CANCEL_RESTORE from whatever thread will
>>>   cause a deadlock.
>>
>> That's the price for using thread suspend/resume unsafe constructs, we
>> never know at which location we will be preempting threads.
>>
>>
>>>
>>>   Is there any way of getting around that?
>>>
>>
>> We could block the notification signal when holding this internal lock.
>> I'll have a look.
>>
>> --
>> Philippe.
>>
>
> Would the enclosed patch be an acceptable solution to the problem? It seems to
> work quite well in my case.
>

We need to block the notification signal each time the printout 
serialization lock is acquired, not only when dumping a backtrace.

It is also preferable not to assume any sigmask disposition when doing 
so, i.e. forcibly unblocking SIGNOTIFY may prove dangerous in the 
future, depending on the call site.

Also, the code should work for both the mercury and cobalt cores.

The commit below should address these issues:

http://git.xenomai.org/xenomai-forge.git/commit/?h=next&id=9ba637cc7902cea15944a894443e22caf0c19139

-- 
Philippe.




More information about the Xenomai mailing list