> Imagine two CPU's doing "disable_bh()" at the same time - neither of them
> running in a BH context. In that case start_bh_atomic() will do no locking
> at all, and you have the race again.
What I understand is that the second CPU will wait in synchronize_bh()
(wait_on_bh()) because it will think that there's a bh running on the
first CPU while the first CPU is simply running in a bh_atomic section of
code. This is the reason I changed synchronize_bh, to handle also the case
in which one CPU is running disable_bh in a irq handler... (and because I
can' t understand why we can't run wait_on_bh from an irq handler..).
I agree that a spinlock would work too but using start_bh_atomic() will
automagically protect us also in run_bottom_halves when we'll read
bh_mask and I think that could perform better...
Maybe I am misunderstooding some bit of code...
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/