lkml.org 
[lkml]   [1999]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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/

\
 
 \ /
  Last update: 2005-03-22 13:51    [W:0.088 / U:1.688 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site