> 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/