On Mon, Nov 17, 2014 at 05:48:00PM +0100, Jan Kiszka wrote:
> On 2014-11-12 18:27, Gilles Chanteperdrix wrote:
> > We do not need trace_hardirqs_on and trace_hardirqs_off for the
> > particular case of IRQs: they are already handled by
> > __ipipe_do_sync_stage.
>
> That was the key: Simply disabling the instrumentations in the
> CONFIG_IPIPE removes all lock state inconsistencies, at least this far:
>
> diff --git a/arch/arm/kernel/entry-header.S b/arch/arm/kernel/entry-header.S
> index d32f8bd..d8e0b2c 100644
> --- a/arch/arm/kernel/entry-header.S
> +++ b/arch/arm/kernel/entry-header.S
> @@ -195,7 +195,7 @@
> #ifdef CONFIG_IPIPE_DEBUG_INTERNAL
> bl __ipipe_bugon_irqs_enabled
> #endif
> -#ifdef CONFIG_TRACE_IRQFLAGS
> +#if defined(CONFIG_TRACE_IRQFLAGS) && !defined(CONFIG_IPIPE)
> @ The parent context IRQs must have been enabled to get here in
> @ the first place, so there's no point checking the PSR I bit.
> bl trace_hardirqs_on
> @@ -203,7 +203,7 @@
> .else
> @ IRQs off again before pulling preserved data off the stack
> disable_irq_notrace
> -#ifdef CONFIG_TRACE_IRQFLAGS
> +#if defined(CONFIG_TRACE_IRQFLAGS) && !defined(CONFIG_IPIPE)
> tst \rpsr, #PSR_I_BIT
> bleq trace_hardirqs_on
> tst \rpsr, #PSR_I_BIT
>
> Will send a patch.
Will this work for other paths in entry.S, such as exceptions or
syscalls?
--
Gilles.
_______________________________________________
Xenomai mailing list
[email protected]
http://www.xenomai.org/mailman/listinfo/xenomai
