From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4AF8646D.1000204@domain.hid> Date: Mon, 09 Nov 2009 19:50:21 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <4AF85A5F.2030203@domain.hid> <4AF85B75.40408@domain.hid> <4AF85EAD.5020408@domain.hid> <4AF86204.6000700@domain.hid> In-Reply-To: <4AF86204.6000700@domain.hid> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Adeos-main] Unchecked ipipe_test_pipeline_from List-Id: General discussion about Adeos List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix Cc: adeos-main , Philippe Gerum 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