public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Bill Pringlemeir <bpringle@sympatico.ca>
To: Richard Gooch <rgooch@ras.ucalgary.ca>
Cc: aki.jain@stanford.edu (Akash Jain),
	linux-kernel@vger.kernel.org, su.class.cs99q@nntp.stanford.edu
Subject: Kernel Stack usage [was: [PATCH] fs/devfs/base.c]
Date: 04 Jun 2001 15:39:02 -0400	[thread overview]
Message-ID: <m2ae3o11d5.fsf_-_@sympatico.ca> (raw)
In-Reply-To: <Pine.LNX.4.21.0106031652090.32451-100000@penguin.transmeta.com> <E156o6c-0005AB-00@the-village.bc.nu> <200106040707.f5477ET11421@vindaloo.ras.ucalgary.ca> <m2elt011y6.fsf@sympatico.ca>
In-Reply-To: Bill Pringlemeir's message of "04 Jun 2001 15:26:25 -0400"

>>>>> Bill Pringlemeir <bpringle@sympatico.ca> writes:

  > There was a discussion on comp.arch.embedded about bounded stack
  > use.  It is fairly easy to calculate the stack usage for call
  > trees, but much more difficult for `DAGs'.  Ie, a recursive
  > functions etc.  I don't know about the policy on recursion in the
  > kernel, but I think it would be bad.

  > Perhaps the checker could be modified to keep track of the call
  > tree and find the largest value used in the tree.  Each function
  > will have a maximum, to which you should add the interrupt
  > handling overhead, which would be calculated in a similar way.
  > This will work if you do not allow re-entrant interrupts and you
  > do not have any `cycles' in the function call hierarchies.

Sorry, I neglected the important case of `alloca', and other variable
length stack allocation functions/constructs.  Maybe this becomes too
restrictive to be useful.

regards,
Bill Pringlemeir


  reply	other threads:[~2001-06-04 19:41 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-05-27 10:12 [PATCH] fs/devfs/base.c 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  0:03     ` Richard Gooch
2001-06-04  6:44     ` Alan Cox
2001-06-04  7:07       ` Richard Gooch
2001-06-04 19:26         ` Bill Pringlemeir
2001-06-04 19:39           ` Bill Pringlemeir [this message]
2001-06-05  6:10           ` 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 10:09       ` Linus Torvalds
2001-06-05  1:41       ` Dawson R Engler
2001-06-05  8:49       ` Ingo Molnar
2001-06-04 20:15     ` Daniel Phillips
2001-06-05  4:24       ` Paul Mackerras

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=m2ae3o11d5.fsf_-_@sympatico.ca \
    --to=bpringle@sympatico.ca \
    --cc=aki.jain@stanford.edu \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rgooch@ras.ucalgary.ca \
    --cc=su.class.cs99q@nntp.stanford.edu \
    /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