On 2011-06-20 21:51, Gilles Chanteperdrix wrote:
> On 06/20/2011 09:41 PM, Jan Kiszka wrote:
>> On 2011-06-20 21:41, Gilles Chanteperdrix wrote:
>>> On 06/20/2011 09:38 PM, Jan Kiszka wrote:
>>>> On 2011-06-20 19:33, Gilles Chanteperdrix wrote:
>>>>> On 06/20/2011 06:43 PM, Jan Kiszka wrote:
>>>>>> On 2011-06-19 17:41, Gilles Chanteperdrix wrote:
>>>>>>> Merged your whole branch, but took the liberty to change it a bit
>>>>>>> (replacing the commit concerning unlocked context switches with comments
>>>>>>> changes only, and changing the commit about xntbase_tick).
>>>>>>
>>>>>> What makes splmax() redundant for the unlocked context switch case? IMO
>>>>>> that bug is still present.
>>>>>
>>>>> No, the bug is between my keyboard and chair. On architectures with
>>>>> unlocked context switches, the Linux task switch still happens with irqs
>>>>> off, only the mm switch happens with irqs on.
>>>>
>>>> Then why do we call xnlock_get_irqsave in
>>>> xnsched_finish_unlocked_switch? Why not simply xnlock_get if irqs are
>>>> off anyway?
>>>
>>> Because of the Xenomai task switch, not the Linux task switch.
>>
>> --verbose please.
> 
> There are two kind of task switches, switches between Linux tasks,
> handled by Linux kernel function/macro/inline asm switch_to(). And those
> between Xenomai tasks, handled by function/macro/inline asm
> xnarch_switch_to().

xnarch_switch_to is the central entry point for everyone. It may decide
to branch to switch_to or __switch_to, or it simply handles all on its
own - that's depending on the arch.

> 
> Since a Linux kernel context switch may still be interrupted by a
> (primary mode) interrupt which could decide to switch context, it can
> not happen with interrupts enabled, due to the way it works (spill the
> registers in a place relative to the SP, then change SP not atomically).
> 
> The Xenomai context switches have no such risk, so, they may happen with
> irqs on, completely.
> 
> In case of relax, the two halves of context switches are not of the same
> kind. The first half of the context switch is a Xenomai switch, but the
> second half is the epilogue of a Linux context switch (which, by the
> way, is why we need skipping all the house keeping in __xnpod_schedule
> in that case, and also why we go to all the pain for keeping the two
> context switches compatible), hence, even on machines with unlocked
> context switches, irqs are off at this point.
> 
> Hope this is more clear.

That's all clear. But it's unclear how this maps to our key question.

Can you point out where in those paths irqs are disabled again (after
entering xnarch_switch_to) and left off for each of the unlocked
switching archs? I'm still skeptical that the need for disable irqs
during thread switch on some archs also leads to unconditionally
disabled hard irqs when returning from xnarch_switch_to.

But even if that's all the case today, we would better set this
requirement in stone:

diff --git a/ksrc/nucleus/pod.c b/ksrc/nucleus/pod.c
index f2fc2ab..c4c5807 100644
--- a/ksrc/nucleus/pod.c
+++ b/ksrc/nucleus/pod.c
@@ -2273,6 +2273,8 @@ reschedule:

        xnpod_switch_to(sched, prev, next);

+       XENO_BUGON(NUCLEUS, !irqs_disabled_hw());
+
 #ifdef CONFIG_XENO_OPT_PERVASIVE
        /*
         * Test whether we transitioned from primary mode to secondary

[ just demonstrating, would require some cleanup ]

Jan

Attachment: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Xenomai-core mailing list
Xenomai-core@gna.org
https://mail.gna.org/listinfo/xenomai-core

Reply via email to