Date: Sun, 2 Apr 2000 01:48:08 -0800 From: Alfred Perlstein <bright@wintelcom.net> To: Gary Jennejohn <garyj@muc.de> Cc: freebsd-current@FreeBSD.ORG Subject: Re: MLEN and crashes Message-ID: <20000402014808.A21029@fw.wintelcom.net> In-Reply-To: <200004020915.LAA00601@peedub.muc.de>; from garyj@muc.de on Sun, Apr 02, 2000 at 11:15:11AM %2B0200 References: <200004020915.LAA00601@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
* Gary Jennejohn <garyj@muc.de> [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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000402014808.A21029>