Date: Thu, 7 Jan 1999 02:07:47 +0000 (GMT) From: Terry Lambert <tlambert@primenet.com> To: csg@physics.purdue.edu (C. Stephen Gunn) Cc: freebsd-hackers@FreeBSD.ORG, ajk@physics.purdue.edu, crh@physics.purdue.edu, jonsmith@physics.purdue.edu, bp@physics.purdue.edu, ab@eas.purdue.edu Subject: Re: NFS problems under 3.0-RELEASE Message-ID: <199901070207.TAA07487@usr09.primenet.com> In-Reply-To: <199901062142.QAA13257@galileo.physics.purdue.edu> from "C. Stephen Gunn" at Jan 6, 99 04:41:57 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> This still doesn't address the problem though. Someone is smashing > this vnode pointer, usually with 0x0100, as far as I can tell. > I've not had the time to digest all of the nfs/vfs changes that > have happened since 3.0 release, but the CVS logs didn't seem to > indicate changes that might address this. Dump from 32 bytes before the problem to 64 bytes after as hex. See if the corruption, in fact, contains the ethernet address of one or both machines. If it does, then what's happening is that a stack address is being used for a structure that's modified later, but the code that gave the address has already returned, somewhere in your kernel. The last place this bug occurred was in the IPFW "reject" response, where the packet was on the stack, queued for send, and then the code doing the queing returned. This resulted in random kernel stack corruption later on in whatever process was in the kernel providing the stack at the time the network interrupt occurred. I suspect there's a number of places in NFS where stack variables are used, but a buffer should have been allocated instead (and later freed by whoever was given the buffer to process). Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199901070207.TAA07487>