Re: Spurious task resume due to SIGSHADOW

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.
Please keep in mind, this is unrelated to the SIGSHADOW race.

-- 
Thanks,
//richard