> 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/