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