Messages in this thread | | | Date | Wed, 5 May 1999 17:28:44 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] SMP race fix [was Re: SMP lockup & 3c509 on 2.2.x [aka. the Deadly 'ping -f']] |
| |
On Thu, 6 May 1999, Andrea Arcangeli wrote: > > Really in this case it's been _far_ better that it harmed since due it I > noticed also the synchronize_irq nono ;) but...
Look at the implementation of "cli()" - when called from within a hardware interrupt, it will do something else than what you think it's doing, and "synchronize_irq()" will basically be a no-op.
> For curiosity I taken a look to the first two usages of synchronize_irq() > that a recursive grep picked up in the device drivers directory. > > drivers/net/de4x5.c:
Bogus. It won't really harm (see no-op above), but it certainly doesn't help either.
> Here from plip.c:
Again, that one looks like it shouldn't actually harm anything, but doesn't help.
For the REAL uses, look at some of the SCSI and sound drivers:
outb(~0, s->ioenh + SV_CODEC_INTMASK); /* disable ints */ synchronize_irq();
where the point of synchronize_irq() is to just wait for current interrupts to exit, because we just asked the card to not send any new ones.
That's still not necessarily a good practice (see my previous email about asynchroneity wrt CPU/device models), but at least it's not a silly no-op like the ones you looked at.
Linus
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |