Messages in this thread | | | Date | Mon, 11 Jan 1999 16:36:07 +0100 (CET) | From | Patrik Rak <> | Subject | SMP problem with (en|dis)able_bh(). |
| |
Hi!
There is a problem with (en|dis)able_bh(). The problem is that if these calls are not protected by some other locking mechanism, things might not work correctly on SMP machines.
The routines look like this (in 2.2.0-pre6, file include/asm-i386/softirq.h):
extern inline void disable_bh(int nr) { bh_mask &= ~(1 << nr); atomic_inc(&bh_mask_count[nr]); synchronize_bh(); }
extern inline void enable_bh(int nr) { if (atomic_dec_and_test(&bh_mask_count[nr])) bh_mask |= 1 << nr; }
Now imagine the situation when processor A is going to disable bottom halves, while B is going to enable it. Now it might go like this (note that many other similar scenarios are possible):
A clears the bit in bh_mask
B decrements bh_mask_count
B sets the bit in bh_mask
A increments bh_mask_count
So, the result is that A thinks that the particular bottom half handler is disabled but it actually is not.
Thus if there is no global lock protecting these calls, this will cause problems. I would bet that especially CONSOLE_BH might suffer from this.
Note that from all supported architectures, only sparc32 does not have this problem, as it uses its own spinlock to protect all functions dealing with bottom half handlers, without making any further assumptions.
Finally, note that this problem affects only SMP boxes, as long as these calls are not allowed to be called from an interrupt.
I would suggest that it is explicitly stated somewhere what conditions must be met when using all these bh calls (and perhaps some others, like those in hardirq.h), and the corresponding code is revised to meet specified requirements. Anyone going to state these conditions?
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/
| |