Messages in this thread |  | | | Date | Sun, 27 Dec 1998 23:09:46 +0100 (CET) | | From | Andrea Arcangeli <> | | Subject | Re: [patch] disable_bh/enable_bh race fix [Re: Program to freeze keyboard in 2.1.131] |
| |
On Sun, 27 Dec 1998, Andrea Arcangeli wrote:
> Ah, understood, the reason for not blocking in synchronize_bh inside an > irq handler is to avoid deadlocking if both the irq handler and the > previous kernel code are running start_bh_atomic()...
I reversed only the irq.c part of my new bh_atomic patch. This way I think that disable_bh() could race only if it's run from an irq handler (probably unlikly to happens), but otherwise it' s safe... The console.c case is still fixed this way.
The synchronize_bh doesn't synchronize if it's run from an irq handler so we could consider the irq case a special not bh_atomic_safe case? Or should we go always safe using a spinlock and do many __cli()?
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/
|  |