> > 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).
Ah, excuse me, I misunderstood, I thought you mean you wanted to protect
the region with the spinlock.
>
> > 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 :)
The point is that to get delayed for 210 usec you must mark the bh with in
a window of time that is near zero (the faster the CPU the smaller the
window).
> 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...
Hmm, I trust that start_bh_atomic() is SMP safe (if it isn't we should
have noticed that because start_bh_atomic() is mainly used to close the
window for SMP races ;). But can you show me the window you seen with a
simple scheme?
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/