From owner-freebsd-current Mon Apr 3 2:56:46 2000 Delivered-To: freebsd-current@freebsd.org Received: from peedub.muc.de (peedub.muc.de [193.149.49.109]) by hub.freebsd.org (Postfix) with ESMTP id 9123B37B562 for ; Mon, 3 Apr 2000 02:56:42 -0700 (PDT) (envelope-from garyj@peedub.muc.de) Received: from peedub.muc.de (localhost [127.0.0.1]) by peedub.muc.de (8.9.3/8.6.9) with ESMTP id LAA48677; Mon, 3 Apr 2000 11:35:02 +0200 (CEST) Message-Id: <200004030935.LAA48677@peedub.muc.de> X-Mailer: exmh version 2.1.0 09/18/1999 To: Alfred Perlstein Cc: Hellmuth Michaelis , freebsd-current@FreeBSD.ORG Subject: Re: MLEN and crashes Reply-To: Gary Jennejohn In-reply-to: Your message of "Mon, 03 Apr 2000 11:13:50 +0200." <20000403023858.F21029@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 03 Apr 2000 11:35:02 +0200 From: Gary Jennejohn Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Alfred Perlstein writes: >* Hellmuth Michaelis [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 / garyj@muc.de garyj@fkr.cpqcorp.net gj@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message