> However, with things like IOAPIC and such, it might be
> possible for two cpus to enter e100intr() simultaneously,
> both read the same status, both see that the interrupt is
> pending, and both thus process the interrupt and race with each other.
>
> Scott, what prevents the above from happening?
Whoa, this question is freaking me out just a little bit: my assumption
is that the device's interrupt line has been masked off at the CPU/PIC
before e100intr() is ever called, so 1) there really isn't any need to
disable device's interrupts from the driver (see eepro100.c), 2) or even
hold a lock unless we shared something critical on the queuing side (see
e1000), and 3) only one e100intr is running. [public spanking in
order?]
I'm not sure what's behind the rest of the bug report, but if you're
saying e100intr() can be running simultaneously on two different CPUs,
then there is a problem because the test for device interrupt and the
acking of device interrupt are two steps that need to be protected with
a lock.
-scott
|