From owner-freebsd-current Tue Sep 29 18:46:45 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA25892 for freebsd-current-outgoing; Tue, 29 Sep 1998 18:46:45 -0700 (PDT) (envelope-from owner-freebsd-current@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 SAA25885 for ; Tue, 29 Sep 1998 18:46:43 -0700 (PDT) (envelope-from tlambert@usr05.primenet.com) Received: (from daemon@localhost) by smtp04.primenet.com (8.8.8/8.8.8) id SAA13302; Tue, 29 Sep 1998 18:46:27 -0700 (MST) Received: from usr05.primenet.com(206.165.6.205) via SMTP by smtp04.primenet.com, id smtpd013256; Tue Sep 29 18:46:24 1998 Received: (from tlambert@localhost) by usr05.primenet.com (8.8.5/8.8.5) id SAA05732; Tue, 29 Sep 1998 18:46:20 -0700 (MST) From: Terry Lambert Message-Id: <199809300146.SAA05732@usr05.primenet.com> Subject: Re: VM mmap file extension bug still exists? (off topic) To: phk@critter.freebsd.dk (Poul-Henning Kamp) Date: Wed, 30 Sep 1998 01:46:20 +0000 (GMT) Cc: abial@nask.pl, freebsd-current@FreeBSD.ORG In-Reply-To: <18821.907067165@critter.freebsd.dk> from "Poul-Henning Kamp" at Sep 29, 98 01:06:05 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-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG > >Hmm... There must be something in e-mail communication which most of us, > >mortals, is still missing... ;-)) > > No, it is a vital principle in many protocols, it's called keep-alive. > > In this case it is responsible for keeping the noise on our mailiing > lists above the tolerable level for normal sane persons. Actually, I've so far been able to demonstrate the bug to three credible people who were willing to look at the source code for more than 5 minutes. Matt Dillion was actually able to demonstrate the corruption on a running system, the first case I have seen of this other than on a 486DX machine. So much for the theory about the 486 L1 cache being buggy and/or the problem being in the 486 specific bcopy code. Julian and I went through and tested the patches, and subsequently rolled a cannonically correct version of the patch that adds the parameter to *_pager_alloc. In the process, we found another boundary problem in vfs_object_create in /sys/kern/vfs_subr.c, where it makes a mapping larger than the backing object when it calls vnode_pager_alloc() (it rounds it up to the page boundary, so even with my original workaround, this case was broken). Luckily, there are people like Julian and John Dyson to give constructive criticism and code to keep me honest... this was definitely not a solo kill on this thing. 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-current" in the body of the message