Re: [patch] PPC/PPC64 port of voluntary preempt patch

[Ingo Molnar <mingo@elte.hu>]

* Scott Wood <scott@timesys.com> wrote:

> Another thing that I forgot to mention is that I have some doubts as
> to the current generic_synchronize_irq() implementation.  Given that
> IRQs are now preemptible, a higher priority RT thread calling
> synchronize_irq can't just spin waiting for the IRQ to complete, as it
> never will (and it wouldn't be a great idea for non-RT tasks either). 
> I see that a do_hardirq() call was added, presumably to hurry
> completion of the interrupt, but is that really safe?  It looks like
> that could end up re-entering handlers, and you'd still have a
> partially executed handler after synchronize_irq() finishes (causing
> not only an extra end() call, but possibly code being executed after
> it's been unloaded, and other synchronization violations).
> 
> If I'm missing something, please let me know, but I don't see a good
> way to implement it without blocking for the IRQ thread's completion
> (such as with the per-IRQ waitqueues in M5).

agreed, this is a hole in generic_synchronize_irq(). I've added
handler-completion waitqueues to my current tree, it will show up in
-Q1.

	Ingo