[Xenomai] Deadlock in CANCEL_RESTORE with CONFIG_XENO_ASYNC_CANCEL during thread suspension

Matthias Schneider ma30002000 at yahoo.de
Wed Apr 23 19:44:22 CEST 2014



----- 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 21, 2014 12:48 PM
> Subject: Re: [Xenomai] Deadlock in CANCEL_RESTORE with CONFIG_XENO_ASYNC_CANCEL during thread suspension
> 
> 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.
> 

I can confirm that the fix is working - thanks for correcting my patch. 
In general, thread suspension on mercury seems to be working quite reliably
now, I will let you know when/if I find another issue.

Matthias




More information about the Xenomai mailing list