Re: [Xenomai-help] xeno-2.3.1 shared interrups BUG?

[Jan Kiszka <jan.kiszka@domain.hid>]

[-- Attachment #1: Type: text/plain, Size: 2126 bytes --]

Jan Kiszka wrote:
> Dmitry Adamushko wrote:
>> On 19/06/07, Jan Kiszka <jan.kiszka@domain.hid> wrote:
>>> apittaluga@domain.hid wrote:
>>>> Hi,
>>>> running a simple test application which spawns a periodic task
>>> writing on a
>>>> serial interface
>>>> the system hangs performing the rt_dev_close.
>>>> The test program ran fine with xeno 2.2.6 with "Shared Interrupts"
>>> enabled,
>>>> so as with
>>>> xeno 2.3.1 with "Shared Interrupts" disabled. It fails with xeno
>>> 2.3.1 with
>>>> "Shared Interrupts" enabled, so the problem seems to be in the shared
>>>> interrupts handling area.
>>>> kernel is 2.6.20 adeos patched
>>>>
>>>> Any suggestion?
>> Does the fix below eliminate the problem?
>>
>> The problem (allegedly) is cause by the following reinitialization at
>> the end of the loop:
>>
>> ...
>>                if (!(intr = intr->next))
>>                        intr = shirq->handlers;
>> ...
>>
>> 'end' may point to some of the elements ... and shirq->handlers may
>> become NULL (all elements have been deleted)..
> 
> Good catch.
> 
>> (white-space damaged version.. enclosed a normal one)
>>
>> --- ksrc/nucleus/intr.c-orig    2007-06-19 13:44:55.090623404 +0200
>> +++ ksrc/nucleus/intr.c 2007-06-19 13:45:53.867440067 +0200
>> @@ -273,7 +273,7 @@ static void xnintr_edge_shirq_handler(un
>>        xnintr_shirq_lock(shirq);
>>        intr = shirq->handlers;
>>
>> -       while (intr != end) {
>> +       while (intr && intr != end) {
>>                int ret, code;
>>
>>                xnstat_runtime_switch(sched,
>>
>>
> 
> But your patch looks incomplete: What if someone removes "end" but
> leaves other handlers behind while we are looping? Neither intr would
> then become NULL nor would we hit the end again. This seems to be more
> tricky...
> 
> Quick idea: mark the xnintr object as being removed, check for this
> state of "end" at the end of the while loop and null'ify "end" in this case.

May also race. So we need both your test and mine, I think. This looks
increasingly ugly, screaming for something different.

Jan


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]