diff options
author | Herbert Xu <herbert@gondor.apana.org.au> | 2007-10-23 11:26:25 +0800 |
---|---|---|
committer | Linus Torvalds <torvalds@woody.linux-foundation.org> | 2007-10-23 09:01:31 -0700 |
commit | a98ce5c6feead6bfedefabd46cb3d7f5be148d9a (patch) | |
tree | 7bbd027e40805966ad908e40f09ffd412a72a88b /drivers/serial/8250_fourport.c | |
parent | 48d2268473a66fe3aa78fb13b09ee59d6ee95073 (diff) | |
download | kernel_samsung_espresso10-a98ce5c6feead6bfedefabd46cb3d7f5be148d9a.zip kernel_samsung_espresso10-a98ce5c6feead6bfedefabd46cb3d7f5be148d9a.tar.gz kernel_samsung_espresso10-a98ce5c6feead6bfedefabd46cb3d7f5be148d9a.tar.bz2 |
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 <herbert@gondor.apana.org.au>
Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/serial/8250_fourport.c')
0 files changed, 0 insertions, 0 deletions