Messages in this thread | | | Date | Fri, 29 Jan 1999 13:28:00 +0100 (CET) | From | Andrea Arcangeli <> | Subject | Re: [patch] race-fix for bottom-half-functions [Re: Subtle trouble in remove_bh().] |
| |
On Fri, 29 Jan 1999, Patrik Rak wrote:
> 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/
| |