Alfred Perlstein writes:
>* Hellmuth Michaelis <[EMAIL PROTECTED]> [000403 02:12] wrote:
>> 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.
>
>When in doubt, ask. Design and Implementation clearly explains the
>kernel stack program as well as some other OS texts afaik.
>
>Just because it's legal C doesn't mean it's allowed, it's perfectly legal
>to do a lot of things in a usermode program that you can't do in a
>kernel routine, smashing the kernel stack is one of these things. :)
>
Yes, but it was perfectly legal to put the structure on the stack
_before_ MLEN was doubled.
If this is the attitude which now obtains, then there's a boatload of
code in the kernel which is incorrect because structs are allocated on
the stack without knowing how big they are at the *time of compilation*.
This isn't a question of "was the routine sppp_params sloppily coded ?"
(which I think Joerg would disagree with, since he wrote it).
I still think that we should nuke csu_hdr from struct slcompress. It's
not used in any code in our tree. I did a make buildowrld and a new
kernel without csu_hdr and there were no errors. The change even made
the kernel BSS 25KB smaller.
---
Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
