| Linus Torvalds wrote:
| > In article <Pine.LNX.4.53.0305070933450.11740@chaos>,
| > Richard B. Johnson <root@chaos.analogic.com> wrote:
| >
| >>You know (I hope) that allocating stuff on the stack is not
| >>"bad".
| >
| >
| > Allocating stuff on the stack _is_ bad if you allocate more than a few
| > hundred bytes. That's _especially_ true deep down in the call-sequence,
| > ie in device drivers, low-level filesystems etc.
| >
| > The kernel stack is a very limited resource, with no protection from
| > overflow. Being lazy and using automatic variables is a BAD BAD thing,
| > even if it's syntactically easy and generates good code.
|
|
| Note that the problem is exacerbated if you have a bunch of disjoint
| stack scopes. For that case, gcc will take the _sum_ of the stacks and
| not the union. rth was kind enough to file gcc PR 9997 on this problem.
Glad to hear that.
| It is turning out to be fairly common problem in the various drivers'
| ioctl handlers. Kernel hackers (myself included) often create automatic
| variables for each case in a C switch statement. (and now I'm having to
| go back and fix that :))
I've written a few of the stack reduction patches. Lots of ioctl functions
need work, so gcc handling it better would be good to have.
I have mostly used kmalloc/kfree, but using automatic variables is certainly
cleaner to write (code). One of the patches that I did just made each ioctl
cmd call a separate function, and then each separate function was able to use
automatic variables on the stack instead of kmalloc/kfree. I prefer this
method when it's feasible (and until gcc can handle these cases).
-- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/