From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <54E77A52.4010806@siemens.com> Date: Fri, 20 Feb 2015 19:17:54 +0100 From: Jan Kiszka MIME-Version: 1.0 References: <54E776E2.2030501@siemens.com> In-Reply-To: <54E776E2.2030501@siemens.com> Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 7bit Subject: Re: [Xenomai] ipipe: issues with ARM exception handling List-Id: Discussions about the Xenomai project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Gilles Chanteperdrix , Xenomai On 2015-02-20 19:03, Jan Kiszka wrote: > Hi Gilles, > > analyzing a lockdep warning on 3.16 with I-pipe enabled, I dug deeper > into the hard and virtual interrupt state management during exception > handling on ARM. I think there are several issues: > > - ipipe_fault_entry should not fiddle with the root irq state if run > over head, only when invoked over root. > - ipipe_fault_exit must not change the root state unless we entered over > head and are about to leave over root - see x86. The current code may > keep root incorrectly stalled after an exception, though this will > probably be fixed up again in practice quickly. And the adjustment of the root irq state after migration has to happen before Linux starts to handle the event. It would basically be a late ipipe_fault_entry. > - do_sect_fault is only called by do_DataAbort and do_PrefetchAbort, > in both cases already wrapped in ipipe_fault_entry/exit, thus it > shouldn't invoke them once again. Sorry, this was a misinterpretation - do_sect_fault is invoked before ipipe_fault_entry. What I need to add, though: - do_DataAbort and do_PrefetchAbort call __ipipe_report_trap after ipipe_fault_entry, thus with hard IRQs on. That's contradicting the pattern used otherwise. If we can avoid this, ipipe_fault_entry/exit would probably only run over the root domain, and things become simpler to sort out. Jan > > Room for optimization: > - ipipe_fault_entry is always called with hard IRQs off from > do_page_fault and do_translation_fault. I suspect this applies to the > remaining callers (do_DataAbort and do_PrefetchAbort ) as well. Thus > the hard IRQ state is actually known at compile time, right? > > I can hack up patches, but I'd like to confirm first that I'm not > missing anything subtle or ARM-specific here. > > Jan > -- Siemens AG, Corporate Technology, CT RTC ITP SES-DE Corporate Competence Center Embedded Linux