From owner-freebsd-current Sun Apr 2 4:57:29 2000 Delivered-To: freebsd-current@freebsd.org Received: from gidora.zeta.org.au (gidora.zeta.org.au [203.26.10.25]) by hub.freebsd.org (Postfix) with SMTP id 8DB3937B5BD for ; Sun, 2 Apr 2000 04:57:18 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: (qmail 15004 invoked from network); 2 Apr 2000 11:57:14 -0000 Received: from bde.zeta.org.au (203.2.228.102) by gidora.zeta.org.au with SMTP; 2 Apr 2000 11:57:14 -0000 Date: Sun, 2 Apr 2000 21:56:55 +1000 (EST) From: Bruce Evans X-Sender: bde@alphplex.bde.org To: Gary Jennejohn Cc: freebsd-current@FreeBSD.ORG Subject: Re: MLEN and crashes In-Reply-To: <200004020915.LAA00601@peedub.muc.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, 2 Apr 2000, Gary Jennejohn wrote: > 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. It's just a bug to allocate big structs on the kernel stack. Almost all structs are too big for utility routines. Top levels of syscall routines and a few other routines that are known not to be called from deep in the kernel stack can use moderately big structs. 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. > 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. The behaviour is unpredictable. Severe cases will be detected as a double fault if you're lucky. The sigset_t changes gave an extra 2K of signal variables to clobber before there is a double fault :-). > 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. Big structs need to be malloced. I think removing the unused bloat in `struct cstate' is the correct fix for this particular allocation. Bruce To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message