Re: [Xenomai] ipipe: issues with ARM exception handling

[Jan Kiszka <jan.kiszka@siemens.com>]

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