From owner-freebsd-hackers Thu Dec 13 13:22: 3 2001 Delivered-To: freebsd-hackers@freebsd.org Received: from iscserv7.nepustil.net (NS.Nepustil.NET [193.96.243.22]) by hub.freebsd.org (Postfix) with ESMTP id F33C537B419 for ; Thu, 13 Dec 2001 13:21:50 -0800 (PST) Received: from peotl.homeip.net (tuebpool-130.pm3.nepustil.net [212.71.200.130]) by iscserv7.nepustil.net (Sendmail) with ESMTP id F37AC79E18; Thu, 13 Dec 2001 22:21:38 +0100 (CET) Received: (from thz@localhost) by peotl.homeip.net (8.11.6/8.11.6) id fBDLIZQ03870; Thu, 13 Dec 2001 22:18:35 +0100 (MET) (envelope-from thz) Date: Thu, 13 Dec 2001 22:12:05 +0100 From: Thomas Zenker To: Matthew Dillon Cc: hackers@freebsd.org Subject: Re: Found NFS data corruption bug... (was Re: NFS: How to make FreeBSD fall on its face in one easy step ) Message-ID: <20011213221204.A2994@peotl.homeip.net> References: <59687.1008231593@winston.freebsd.org> <200112131058.fBDAwSR66790@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Mailer: Mutt 1.0.1i In-Reply-To: <200112131058.fBDAwSR66790@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Dec 13, 2001 at 02:58:28AM -0800 Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Dec 13, 2001 at 02:58:28AM -0800, Matthew Dillon wrote: > > @#$@#$ crap. I think I found a dirty-mmap edge case with truncation. > It requires a change to vm_page_set_validclean(), which of course is > one of the core routines in the VM system. > > Basically what happens is that ftruncate() calls vnode_pager_setsize() > which eventually calls vm_page_set_validclean(). > > If you happened to mmap() the truncation point shared R+W and > dirty it, then truncate to something that isn't a multiple DEV_BSIZE.. > for example, if you were to truncate to an offset of '10', and a buffer Matt, what the hell, this seems to very near by a problem I wanted to report since a week: in a data acquisition I have a write process writing to a file backed shared mmapped ringbuffer. There can be several reader processes on this this ringbuffer. Now once i killed the writer for resizing of the ringbuffer and forgot about the readers. The writer truncated the database without unlinking it before. This lead the readers to be running for ever, it seemed so at least. After attaching with gdb I saw, that they were only page faulting nothing more, for ever.... Something similar I saw with netscape going mad. cheers, Thomas To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message