>From the keyboard of Bruce Evans:
> It's just a bug to allocate big structs on the kernel stack.
Please specify "big"! :-)
I wonder how too "big" can be detected. The code in question is perfectly
valid syntactically and semantically correct C-code.
If a piece of code being considered buggy depends on the size of some
externally defined "thing" (like the kernel stack size in this case)
something - IMHO - is not in a good condition.
Perhaps a sentence like "It's just a bug to allocate structs on the
kernel stack" (note the missing "big") has to be put in style. Or a
macro like (this is just a cheap shoot in the dark)
void
kernel_subr(void)
{
ALLOCATE_STRUCT_ON_STACK(struct bigstruct bigstr);
....
could be created to check for potentially stack overflow at compile
time and/or runtime and people are forced in style(9) to use it.
> 512 bytes is probably too big for i386's now. The effective kernel stack
> size was shrunk by about 2K by the sigset_t changes, so there is only
> about 5K of kernel stack.
Then isn't it time to make the kernel stack larger ?
Please don't misunderstand. I can fully accept accecpt and acknowledge what
you write (i've converted the piece of code in question to malloc'ing its
data already), i'm just a bit concerned because its so perfectly legal and
common to allocate a struct on the stack that i fear just that i and
probably other don't think about it if it were not made absolutely clear
and possibly enforced somehow to never do this in kernel land.
hellmuth
--
Hellmuth Michaelis Tel +49 40 55 97 47-70
HCS Hanseatischer Computerservice GmbH Fax +49 40 55 97 47-77
Oldesloer Strasse 97-99 Mail hm [at] hcs.de
D-22457 Hamburg WWW http://www.hcs.de
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
