Messages in this thread | | | Date | Mon, 1 Feb 1999 18:13:19 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [patch] race-fix for bottom-half-functions [Re: Subtle trouble in remove_bh().] |
| |
On Mon, 1 Feb 1999, Patrik Rak wrote:
> And the window I mean is NOT the one between get/clear_active_bhs(). Look: > > Processor A Processor B > ----------- ----------- > enters do_irq > handles irq > marks some bh > gets to run_bottom_half() > acquires both locks > reads active_bhs enters do_irq > starts executing them handles irq > marks some bh > gets to run_bottom_half() > does not get the lock, so it exits > releases both locks and exits exits from do_irq > exits from do_irq. > > So, the bh marked by B gets delayed until the next interrupt arrives, > and is not executed ASAP.
True.
> I know that bhs are expected to be delayed in principle (that's why they > exist), but this delay is not really necessary and is caused by design.
Right, but I don't think it's an issue and I am not going to change it.
> I was not speaking about races this time. My idea was about theoretical > chance that some processors execute normal non-irq stuff, some hard-irq > stuff, but none of them executes soft-irq stuff because the double locking > always prevents it. Just forget it, it's too artificial.
The point is that you marked the bh while do_bottom_half() was running on the other CPU and the bh you marked will wait for the next do_bottom_half() to run. Yes, it could be more finegrined, but as just said I don't think it's an issue...
> BTW, current do_IRQ() does not use get_active_bhs() macro.
Fixed.
> BTW2, the comment at run_bottom_halves() is obsolete.
Which? ;)
> Hmm, I suggest that we just stop this discussion, as it does not lead > anywhere anyway and nobody else seems to think this is an issue...
I don't think this is an issue too (and it's sure not a race ;).
Andrea Arcangeli
- 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/
| |