> Yes, I seen the subtle mask race the day after I fixed the running bug
> (making bh_mask_count atomic_t). atomic_t seems far enough in real world
> though.
Yes, if the count is not atomic_t, it could be really disastrous, as the
count might got screwed permanently. This way you.
> I just fixed the subtle race with a `slow' spinlock here. The new spinlock
> make atomic the bh_mask_count and bh_mask settings. Obviously with a
> spinlock bh_mask_count return to be a simple int. I should have posted my
Obviously.
> patch here some weeks ago. Browse or ask if you need it.
Thanks, but I don't have a SMP box (unfortunately :).
> I can't se a way to fix the thing without using a spinlock. To see the
There is no such way. If you need to use two or more resources atomically,
then you must protect the accesses by some kind of exclusive lock.
> subtle race you can imagine an mdelay(1000) between the atomic_t operation
> and the bh_mask setting (or the reverse).
The problem is even more important because such delay may actually occur
there - imagine an interrupt would arrive at the place you describe...
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/