> Well it fullfils these assumptions then. But what about SMP boxes? Can't
> one processor execute init/remove_bh while the other one runs other
> init/remove_bh or enable/disable_bh? It could lead to bh_mask corruption
> then because expressions like ( bh_mask |= 1 << nr ) are not atomic.
I think to see your point now. Think this running on the same CPU:
task 1 irq handler
------------- -----------
start_bh_atomic();
remove_bh(BH_1)
(eax = bh_mask) == 0;
irq_X
mark_bh(BH_3)
/* not run bh handlers because bh
atomic */
ret_from_irq_X
eax &= ~(1 << nr)
bh_mask = eax
end_bh_atomic();
So we lose the BH_3 mark. Some other subtle scenario like this could raise
similar problems.
The fix should be simply to use set/clear_bit instead of &= |= in
init_bh/remove_bh. Do you agree?
> I think it's not me who has problem seeing the possible races :)
I have not understood very well due english (eventually reply me
privately)... but since you smailed I smail too here ;).
> the double locking is not very nice implementation, is it? You can
> delay the software interrupt for whole 210 usec, and in theory,
This is true but it's not an issue.
> there is a chance you can delay it forever.
No, or at least I can't see your point. My point is that
clear_active_bhs() is perfectly atomic and remove only what you just done
now. Other bh that get raised in the meantime will be run in the next
do_bottom_half(). Do you agree?
> BTW, don't you know why m68k does not trigger the software irq line
> in mark_bh()? I thought this is what software irq is for...
I don't know m68k arch...
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/