Re: Dovetail/Xenomai 3: Timer tick locking problem

[Philippe Gerum <rpm@xenomai.org>]

Florian Bezdeka <florian.bezdeka@siemens.com> writes:

> On Thu, 2024-06-06 at 10:18 +0200, Philippe Gerum wrote:
>> > When running over an OOB task that is currently owning nklock, we will
>> > release the lock unconditionally, leaving the task "unprotected" /
>> > unsynchronized. Right?
>> 
>> No, the only way for a task to hold the ugly lock safely is to disable
>> IRQs if it has to compete with an IRQ handler. So this scenario is by
>> definition a usage bug on the application/driver side, not on the
>> infrastructure's. Meanwhile, the _irqsave() variant prevents spurious
>> lock release in recursion using a special marker in the saved interrupt
>> flags.
>
> I just checked all nklock usages. Most of them are indeed using the IRQ
> safe variants. But:
>
> In xnthread_relax() we have:
>
>     splmax();
>     xnlock_get(&nklock);
>     xnthread_suspend(...);
>         xnlock_get_irqsave(&nklock, s);
>         xnlock_put_irqrestore(&nklock, s);
>     splnone();
>
> As xnthread_suspend() is using the _irqsave() variants, it's basically
> a noop, the recursion will be detected / handled correctly.
>
> What happens, if right after splnone() the Xenomai timer tick is
> handled?

At this point, the current task is relaxed and does not hold the nklock
anymore. It's been released by ___xnsched_run() <- xnthread_suspend(),
on the exit path.

-- 
Philippe.