Re: linux-kernel-digest V1 #2222
Masumi Ellis (jone@netwiz.net)
Mon, 13 Jul 1998 05:34:46 -0700
> On Mon, 13 Jul 1998, Linux Torvalds wrote:
> On Mon, 13 Jul 1998, Andrea Arcangeli wrote:
> > On Sat, 11 Jul 1998, Linus Torvalds wrote:
> >
> > >No, the interrupt stack issue must be a red herring. We must _never_ get
> > >nested interrupts, no matter what. Using a separate stack is never an
> > >acceptable solution, it just means we have other problems.
> >
> > Hmm I can' t see any other problem. Can anybody show me which other
> > problems are?
> >
> > One month ago I developed a didactical kernel for mips for Univ. and since
> > I didn' t want to have to deal with mm at all I taken the most
> > strightforward way to allocate a static stack pool per interrupt. It
> > worked fine and it seems to me very more simple.
>
> 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>
This is no doubt wrong - my only experience of memory fragging is in
database engines - but i feel like sharing :)
Why not have the stack come from one "pool" of memory and have the
inode/dentry stuff come from another? I would imagine the buddy system
would be pretty good if all the allocation were of a regular size, say
8k.
Not going to help stop stack overflows but it might make fork() more
likely to happen consistantly.
I feel sure i'll regret sending this shortly. ho-hum
-
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