Re: Spurious task resume due to SIGSHADOW

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?

Because:

"A nesting count is maintained so that rt_task_suspend() and
rt_task_resume() must be used in pairs."

> - In some cases it happens that the task resumes to execute
> - It resumes because a Linux signal is pending, being SIGSHADOW
> 
> Since SIGSHADOW is internally used to suspend a task, this alerted me.
> So, I suspect the following issue:
> When xnthread_suspend() fires SIGSHADOW using
> __xnthread_signal(thread, SIGSHADOW, SIGSHADOW_ACTION_HARDEN); nothing
> seems to prevent the case where the target task enters the primary
> domain right before it sees SIGSHADOW. In the next step
> do_sigwake_event() causes it to resume instead of sleeping.
> 
> Hmm?
> 

Traces to confirm this theory would be good. But it could indeed be
problematic that the target state (__THREAD_S_SUSPENDED) is only tracked
in userspace where the scheduler has no access to while waking a task.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center