Re: Spurious task resume due to SIGSHADOW

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.

What race do you see with the "fix" applied?
Maybe I'm focusing too strong on the symptom that a suspended task wakes up?

> The fundamental issue we need to solve with remote suspension/resumption
> is the asynchronicity of the command vs. the pending (and
> non-suppressible) signals. One idea I had is to use a separate
> SIGSHADOW_ACTION_SUSPEND and perform a self-suspension instead of just a
> hardening. That works nicely for resolving the issue you found, but it
> creates a new race between this pending signal and remote resumption.
>
> We likely rather need some additional state flag in the thread to encode
> "suspend is pending" which can do the right thing before a thread is
> returning to userland and can also be cleared from remote if suspension
> is lifted quickly again.
>
> Did I say that asynchronous thread suspension is a horrible concept to
> implement correctly?

Yeah. :-/

-- 
Thanks,
//richard