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

[Ingo Molnar]

* Scott Wood <scott@xxxxxxxxxxx> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/