From owner-freebsd-current Sun Apr 2 1:23:14 2000 Delivered-To: freebsd-current@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 51B7C37BD94 for ; Sun, 2 Apr 2000 01:22:59 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.10.0/8.10.0) id e329m9i25647; Sun, 2 Apr 2000 01:48:09 -0800 (PST) Date: Sun, 2 Apr 2000 01:48:08 -0800 From: Alfred Perlstein To: Gary Jennejohn Cc: freebsd-current@FreeBSD.ORG Subject: Re: MLEN and crashes Message-ID: <20000402014808.A21029@fw.wintelcom.net> References: <200004020915.LAA00601@peedub.muc.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200004020915.LAA00601@peedub.muc.de>; from garyj@muc.de on Sun, Apr 02, 2000 at 11:15:11AM +0200 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG * Gary Jennejohn [000402 01:43] wrote: > This is a HEADS UP. > > The recent increase in MLEN from 128 to 256 bytes led to very surprising > problems with the latest, so called developers', version of isdn4bsd. > > The new version uses slcompress by default. The change in MLEN makes > struct slcompress 2KB larger than it used to be. BTW the entry csu_hdr > in struct cstate, which has size MLEN, is not used anywhere in the kernel > that I could find. csu_hdr is what leads to the increase in the size of > struct slcompress. There's a comment in slcompress.h which states that > MAX_HDR should really be defined as 128 and not MLEN. Maybe this should > be taken to heart and MAX_HDR redefined as 128 and not MLEN. > > But I digress. > > struct slcompress is now in struct sppp, which is passed by ispppcontrol > as part of an ioctl call. Eventually the kernel lands in sppp_params, > which does a copyin to a struct spppreq (which contains struct sppp) on > the kernel stack. Because struct sppp is 2KB larger as a result of the > change in MLEN the copyin overruns the kernel stack which immediately > results in a crash - no trace output, no ddb, zilch. > Interesting is that the crash only happens on a Pentium (tested with > a II and III). On a K6 it doesn't happen. AFAICT it's not related to > using the FPU for copyin/copyout since I turned that functionality > off using npx0 flags and the crash still happened. > > Moving the struct spppreq into global address space solves the problem, > but that makes the kernel BSS somewhat larger. Redefining MAX_HDR to be > 128 also fixes the problem, even with the struct spppreq on the stack. > > If those of you using slcompress start seeing problems then they may well > be due to the increase in MLEN. > > I wonder how wise it was to change MLEN without more testing. But hey, > this is -current, that's what it's there for. > > Anyway, I think MAX_HDR should be hardwired to 128 in slcompress. Any > comments ? > Why not just malloc the structure instread of using a stack variable? Various other parts of the kernel do so to get around this problem, since we're heading up SMP now it _not_ the time to start using global variables. -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] "I have the heart of a child; I keep it in a jar on my desk." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message