Re: Spurious task resume due to SIGSHADOW

On 14.05.26 13:08, Richard Weinberger wrote:
> On Thu, May 14, 2026 at 12:00 PM 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:
>>> diff --git a/kernel/cobalt/dovetail/kevents.c b/kernel/cobalt/dovetail/kevents.c
>>> index 7402e2ef6..d72c3788b 100644
>>> --- a/kernel/cobalt/dovetail/kevents.c
>>> +++ b/kernel/cobalt/dovetail/kevents.c
>>> @@ -145,6 +145,14 @@ static int handle_sigwake_event(struct task_struct *p)
>>>        if (xnthread_test_state(thread, XNRELAX))
>>>                goto out;
>>>
>>> +       if (sigismember(&p->pending.signal, SIGSHADOW))
>>> +               goto out;
>>> +
>>> +       if (sigismember(&p->signal->shared_pending.signal, SIGSHADOW))
>>> +               goto out;
>>> +
>>
>> None of this will work, and I'm afraid your approach that you shared
>> yesterday for retired Xenomai versions will also fail. I played with
>> something even more targeted than the above, and different scenarios,
>> e.g. task startup, were starting to lock-up. No surprise, we are
>> breaking SIGSHADOW here.
> 
> Please help me to understand why this approach is doomed.
> I fully understand that unconditionally checking for SIGSHADOW and returning
> from handle_sigwake_event() is wrong.
> The check should happen only if task p has the state flag XNSUSP set.

Besides identifying the condition when we should act here (you
practically cannot peek into siginfo), the main issue is that the signal
will not be consumed but just deferred. This can easily cause confusion
or worse things later on after resuming execution again.

> 
> What race do you see with the "fix" applied?

I didn't debug further, but the issue was that your test case was no
longer starting its tasks.

> Maybe I'm focusing too strong on the symptom that a suspended task wakes up?

Yes, we need to think the suspension/resumption with all its branches
holistically. I've tried that, and will share a patch in a minute.
Spoiler: There might have been another case.

Jan

-- 
Siemens AG, Foundational Technologies
Linux Expert Center