From a98ce5c6feead6bfedefabd46cb3d7f5be148d9a Mon Sep 17 00:00:00 2001 From: Herbert Xu Date: Tue, 23 Oct 2007 11:26:25 +0800 Subject: [PATCH] Fix synchronize_irq races with IRQ handler As it is some callers of synchronize_irq rely on memory barriers to provide synchronisation against the IRQ handlers. For example, the tg3 driver does tp->irq_sync = 1; smp_mb(); synchronize_irq(); and then in the IRQ handler: if (!tp->irq_sync) netif_rx_schedule(dev, &tp->napi); Unfortunately memory barriers only work well when they come in pairs. Because we don't actually have memory barriers on the IRQ path, the memory barrier before the synchronize_irq() doesn't actually protect us. In particular, synchronize_irq() may return followed by the result of netif_rx_schedule being made visible. This patch (mostly written by Linus) fixes this by using spin locks instead of memory barries on the synchronize_irq() path. Signed-off-by: Herbert Xu Acked-by: Benjamin Herrenschmidt Signed-off-by: Linus Torvalds --- kernel/irq/manage.c | 20 ++++++++++++++++++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 80eab7a04205..1f314221d534 100644 --- a/kernel/irq/manage.c +++ b/kernel/irq/manage.c @@ -29,12 +29,28 @@ void synchronize_irq(unsigned int irq) { struct irq_desc *desc = irq_desc + irq; + unsigned int status; if (irq >= NR_IRQS) return; - while (desc->status & IRQ_INPROGRESS) - cpu_relax(); + do { + unsigned long flags; + + /* + * Wait until we're out of the critical section. This might + * give the wrong answer due to the lack of memory barriers. + */ + while (desc->status & IRQ_INPROGRESS) + cpu_relax(); + + /* Ok, that indicated we're done: double-check carefully. */ + spin_lock_irqsave(&desc->lock, flags); + status = desc->status; + spin_unlock_irqrestore(&desc->lock, flags); + + /* Oops, that failed? */ + } while (status & IRQ_INPROGRESS); } EXPORT_SYMBOL(synchronize_irq); -- 2.30.2