Re: [Xenomai-core] Potential problem with rt_eepro100

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

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

Am 04.11.2010 00:18, Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Am 04.11.2010 00:11, Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Am 03.11.2010 23:11, Jan Kiszka wrote:
>>>>> Am 03.11.2010 23:03, Jan Kiszka wrote:
>>>>>> But we not not always use atomic ops for manipulating status bits (but
>>>>>> we do in other cases where this is no need - different story). This may
>>>>>> fix the race:
>>>>> Err, nonsense. As we manipulate xnsched::status also outside of nklock
>>>>> protection, we must _always_ use atomic ops.
>>>>>
>>>>> This screams for a cleanup: local-only bits like XNHTICK or XNINIRQ
>>>>> should be pushed in a separate status word that can then be safely
>>>>> modified non-atomically.
>>>> Second try to fix and clean up the sched status bits. Anders, please
>>>> test.
>>>>
>>>> Jan
>>>>
>>>> diff --git a/include/nucleus/pod.h b/include/nucleus/pod.h
>>>> index 01ff0a7..5987a1f 100644
>>>> --- a/include/nucleus/pod.h
>>>> +++ b/include/nucleus/pod.h
>>>> @@ -277,12 +277,10 @@ static inline void xnpod_schedule(void)
>>>>  	 * context is active, or if we are caught in the middle of a
>>>>  	 * unlocked context switch.
>>>>  	 */
>>>> -#if XENO_DEBUG(NUCLEUS)
>>>>  	if (testbits(sched->status, XNKCOUT|XNINIRQ|XNSWLOCK))
>>>>  		return;
>>>> -#else /* !XENO_DEBUG(NUCLEUS) */
>>>> -	if (testbits(sched->status,
>>>> -		     XNKCOUT|XNINIRQ|XNSWLOCK|XNRESCHED) != XNRESCHED)
>>>> +#if !XENO_DEBUG(NUCLEUS)
>>>> +	if (!sched->resched)
>>>>  		return;
>>>>  #endif /* !XENO_DEBUG(NUCLEUS) */
>>> Having only one test was really nice here, maybe we simply read a
>>> barrier before reading the status?
>>>
>>
>> I agree - but the alternative is letting all modifications of
>> xnsched::status use atomic bitops (that's required when folding all bits
>> into a single word). And that should be much more costly, specifically
>> on SMP.
> 
> What about issuing a barrier before testing the status?
> 

The problem is not about reading but writing the status concurrently,
thus it's not about the code you see above.

Jan


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