> Even with poll instead of interrupts, all SCSI code is going to use the
> buffer cache and try to get the io request spin lock. During Oops
> dumping, neither are safe. If the Oops occurred during earlier I/O
> processing and we do *any* disk I/O from Oops recovery then we are
> violating all the constraints on I/O reentrancy. If we are lucky we just
> hang on a spin lock, if we are unlucky we corrupt kernel structures and
> make the problem worse.
>
> The only safe method of doing I/O inside Oops recovery is one that does
> not use kernel interrupts, does not use kernel DMA, does not use buffer
> cache, does not use any spin locks. Forget about doing I/O during Oops
> unless you can meet these criteria. Serial console does, very little else
> is suitable.
At least the problem with the spin locks can be solved just en passer.
Myself and a few other people are considering solving some of the deadlock
issues that plague especially highly intelligent hardware using lock-free
data structures. These will also provide some key advantages for other
problems we're thinking about.
Ralf
-
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/