Date: Sun, 2 Apr 2000 21:56:55 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Gary Jennejohn <garyj@muc.de> Cc: freebsd-current@FreeBSD.ORG Subject: Re: MLEN and crashes Message-ID: <Pine.BSF.4.21.0004022118510.1442-100000@alphplex.bde.org> In-Reply-To: <200004020915.LAA00601@peedub.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0004022118510.1442-100000>