Date: Thu, 13 Dec 2001 22:12:05 +0100 From: Thomas Zenker <thz@tuebingen.netsurf.de> To: Matthew Dillon <dillon@apollo.backplane.com> 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> In-Reply-To: <200112131058.fBDAwSR66790@apollo.backplane.com>; from dillon@apollo.backplane.com on Thu, Dec 13, 2001 at 02:58:28AM -0800 References: <59687.1008231593@winston.freebsd.org> <200112131058.fBDAwSR66790@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20011213221204.A2994>