From: Paul Mackerras <paulus@samba.org>
To: Daniel Phillips <phillips@bonn-fries.net>
Cc: Linus Torvalds <torvalds@transmeta.com>,
Richard Gooch <rgooch@ras.ucalgary.ca>,
Akash Jain <aki.jain@stanford.edu>,
alan@lxorguk.ukuu.org.uk, linux-kernel@vger.kernel.org,
su.class.cs99q@nntp.stanford.edu
Subject: Re: [PATCH] fs/devfs/base.c
Date: Tue, 5 Jun 2001 14:24:25 +1000 (EST) [thread overview]
Message-ID: <15132.24313.192723.285372@argo.ozlabs.ibm.com> (raw)
In-Reply-To: <01060422150505.08443@starship>
In-Reply-To: <Pine.LNX.4.21.0106031652090.32451-100000@penguin.transmeta.com> <01060422150505.08443@starship>
Daniel Phillips writes:
> We'd better know the upper bound of interrupt allocations or we have an
> accident waiting to happen. How much of the kernel stack is reserved
> for interrupts?
Since interrupt handlers generally run with other interrupts enabled,
and only their own interrupt disabled, it seems to me that the bound
on how much stack space you need to leave for interrupt handlers
depends on how many different interrupts you have in the system. On a
large system there could easily be tens or even hundreds of active
devices, all with different IRQs. It would be possible (although
unlikely) for them to all to interrupt at just the right time to get
all their handlers stacked, and that could easily overflow the stack.
One solution would be to start running interrupt handlers with
interrupts disabled (__cli) when they are getting close to being too
deeply nested - it would not be hard to check the stack pointer and if
there is less than some defined amount of stack space left then we
don't do the __sti before calling the handler.
Paul.
next prev parent reply other threads:[~2001-06-05 4:24 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-05-27 10:12 Akash Jain
2001-05-27 13:21 ` Richard Gooch
2001-05-28 14:43 ` Maximum size of automatic allocation? (was: [PATCH] fs/devfs/base.c) Daniel Phillips
2001-06-03 23:55 ` [PATCH] fs/devfs/base.c Linus Torvalds
2001-06-04 6:44 ` Alan Cox
2001-06-04 10:09 ` Linus Torvalds
2001-06-05 1:41 ` Dawson R Engler
2001-06-05 8:49 ` Ingo Molnar
2001-06-04 7:07 ` Richard Gooch
2001-06-04 19:26 ` Bill Pringlemeir
2001-06-04 19:39 ` Kernel Stack usage [was: [PATCH] fs/devfs/base.c] Bill Pringlemeir
2001-06-05 6:10 ` [PATCH] fs/devfs/base.c H. Peter Anvin
2001-06-05 6:56 ` Alan Cox
2001-06-05 11:37 ` Andrew Morton
2001-06-05 21:38 ` Pavel Machek
2001-06-04 20:15 ` Daniel Phillips
2001-06-05 4:24 ` Paul Mackerras [this message]
2001-06-04 0:03 ` Richard Gooch
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=15132.24313.192723.285372@argo.ozlabs.ibm.com \
--to=paulus@samba.org \
--cc=aki.jain@stanford.edu \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=linux-kernel@vger.kernel.org \
--cc=phillips@bonn-fries.net \
--cc=rgooch@ras.ucalgary.ca \
--cc=su.class.cs99q@nntp.stanford.edu \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®