From owner-freebsd-hackers Wed Jan 6 18:08:53 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA12573 for freebsd-hackers-outgoing; Wed, 6 Jan 1999 18:08:53 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from smtp04.primenet.com (smtp04.primenet.com [206.165.6.134]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA12567 for ; Wed, 6 Jan 1999 18:08:51 -0800 (PST) (envelope-from tlambert@usr09.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id TAA19330; Wed, 6 Jan 1999 19:08:08 -0700 (MST) Received: from usr09.primenet.com(206.165.6.209) via SMTP by smtp04.primenet.com, id smtpd019201; Wed Jan 6 19:07:59 1999 Received: (from tlambert@localhost) by usr09.primenet.com (8.8.5/8.8.5) id TAA07487; Wed, 6 Jan 1999 19:07:47 -0700 (MST) From: Terry Lambert Message-Id: <199901070207.TAA07487@usr09.primenet.com> Subject: Re: NFS problems under 3.0-RELEASE To: csg@physics.purdue.edu (C. Stephen Gunn) Date: Thu, 7 Jan 1999 02:07:47 +0000 (GMT) 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 In-Reply-To: <199901062142.QAA13257@galileo.physics.purdue.edu> from "C. Stephen Gunn" at Jan 6, 99 04:41:57 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > 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