Oh, having separate interrupt stacks _works_, and on some architectures it
makes tons of sense, because on some architectures the CPU quite naturally
allows it. On the x86, it's just fairly painful, because the CPU uses the
stack without asking anybody (unlike most RISC chips where the stack has
to be explicitly used by software).
What I meant was that if there are nested interrupts (which is illegal,
and which was what Alan talked about), then the resulting stack overflow
cannot be fixed by having a separate stack. In fact, with a per-interrupt
stack a nested interrupt would trash the stack completely.
We _can_ use separate stacks to lessen the total amount of stack space
needed, but if interrupt handlers are using a lot of stack space there is
something fairly wrong with the picture in the first place.
So the "red herring" was a comment not on the fact that separate stacks
are bad, but on the fact that I don't think they are a solution to the
problem.
> BTW, some time ago I got stack overflows with 2.1.5x too trying to use the
> ->command callback instead of the queuecommand one in ppa (ZIP parallel
> drive).
The SCSI subsystem can be made to recurse forever if misused. And one of
my worries with the SCSI subsystem is that it is too complex to be
understood by mere mortals (and yes, I count myself into that category),
so it is fairly easy to get wrong.
Again, separate stacks can't help it, it can only hide the bugs longer due
to having more total stack space available.
Linus
-
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.altern.org/andrebalsa/doc/lkml-faq.html