On 05.04.22 17:53, Richard Weinberger wrote: > ----- Ursprüngliche Mail ----- >> Von: "Jan Kiszka" <jan.kis...@siemens.com> >> I would like to have an explanation or prove points (traces, assertions) >> that we actually see xnthread_relax overtaking the delivery of its own >> wakework. > > I can re-test with something like that: > > diff --git a/kernel/cobalt/thread.c b/kernel/cobalt/thread.c > index beda67e18..4c100b645 100644 > --- a/kernel/cobalt/thread.c > +++ b/kernel/cobalt/thread.c > @@ -2159,6 +2159,7 @@ void xnthread_relax(int notify, int reason) > pipeline_clear_mayday(); > > trace_cobalt_shadow_relaxed(thread); > + WARN_ON_ONCE(irq_work_is_busy(&wakework.inband_work.work)); > } > EXPORT_SYMBOL_GPL(xnthread_relax); > > But I fear this might take some time. The KASAM spat happened only once > and also only after the test ran for almost 5 days.
How about additionally widening the suspected race window by adding a delay to lostage_task_wakeup? Jan -- Siemens AG, Technology Competence Center Embedded Linux
