Messages in this thread | | | Date | Sat, 30 Jan 1999 23:56:19 +0100 (CET) | From | Patrik Rak <> | Subject | Re: [patch] race-fix for bottom-half-functions [Re: Subtle trouble in remove_bh().] |
| |
On Fri, 29 Jan 1999, Andrea Arcangeli wrote:
> I think to see your point now. Think this running on the same CPU: ... > 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?
Yes. (Actually, that's what I already said two messages ago).
> > 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.
Oh, so 210 usec delay is not a problem? Well, I thought it is whole eternity for CPUs today :)
> > 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?
That's not what I had in mind. I wrote about soft/hardirq_trylock(). Isn't there a (however slight) chance that alway some other processor than the one in do_bottom_half is holding one of these lock? I am afraid there is...
Patrik
- 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/
| |