Gilles Chanteperdrix wrote:
> Jan Kiszka wrote:
>> Gilles Chanteperdrix wrote:
>>> Jan Kiszka wrote:
>>>> Hi Philippe,
>>>>
>>>> just noticed: The __ipipe_check_percpu_access of __ipipe_get_cpu_var,
>>>> added in 2.6.29, makes ipipe_test_pipeline_from unusable for debugging
>>>> purposes. It now triggers a false positive warning if the caller did not
>>>> disabled interrupts or stalled its pipeline. One such user under Xenomai
>>>> is rthal_local_irq_disabled, and that is used to check RTDM driver
>>>> handlers /wrt leaking IRQ masks.
>>> It does not look like a false positive. If the task issuing the call to
>>> rthal_local_irq_disabled function was migrated at the wrong time, it
>>> could check the stall flag on the wrong cpu.
>> Unless you want to test the migration logic itself, a plain task in
>> whatever domain should never see a CPU-depend rthal_local_irq_disabled -
>> migration should never alter the context in this respect.
>>
>>> So, it looks like
>>> rthal_local_irq_disabled should be fixed to turn off irqs during the check.
>>>
>> Would work, but would also be more heavy-weighted then needed.
> 
> If it is debug stuff, does the heavy-weight matter that much?
> 

Actually, I'm no longer sure that a preemption check for
ipipe_stall_pipeline_from makes sense at all. Am I missing some case?

Jan

-- 
Siemens AG, Corporate Technology, CT SE 2
Corporate Competence Center Embedded Linux

_______________________________________________
Adeos-main mailing list
[email protected]
https://mail.gna.org/listinfo/adeos-main

Reply via email to