Re: Spurious task resume due to SIGSHADOW

On 12.05.26 11:16, Richard Weinberger wrote:
> On Tue, May 12, 2026 at 10:50 AM Jan Kiszka <[email protected]> wrote:
>>
>> On 12.05.26 09:19, Richard Weinberger wrote:
>>> On Tue, May 12, 2026 at 7:50 AM Jan Kiszka <[email protected]> wrote:
>>>>
>>>> On 11.05.26 23:49, Richard Weinberger wrote:
>>>>> I'm currently debugging an issue on a very old Xenomai system, while
>>>>> reading the source I noticed that the very same issue could also exist
>>>>> on recent Xenomai releases.
>>>>>
>>>>> What I see is the following:
>>>>> - A task gets suspended and unblocked using rt_task_suspend() and
>>>>> rt_task_unblock()
>>>>
>>>> This is intentionally rt_task_unblock instead of rt_task_resume?
>>>
>>> From what I can tell, yes.
>>>
>>>> Because:
>>>>
>>>> "A nesting count is maintained so that rt_task_suspend() and
>>>> rt_task_resume() must be used in pairs."
>>>
>>> The application has non-trivial thread management, from what I can
>>> tell, it's fine.
>>>
>>
>> Unlikely, because it will completely confuse tcb->suspends, preventing
>> future suspends for the task that was not properly resumed.
> 
> Well, the application does rt_task_suspend(), followed by rt_task_unblock().
> But unblock does not resume a task. That's why the application later
> uses rt_task_resume().
> So, it should be paired.

So, at least for resume story, the unblock is pointless at best.

> Please keep in mind, this is unrelated to the SIGSHADOW race.
> 

Right, but we didn't know until you had a separate reproducer.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center