Date: Sun, 31 Jul 2005 23:18:58 +0300 From: Giorgos Keramidas <keramida@freebsd.org> To: Joseph Koshy <joseph.koshy@gmail.com> Cc: freebsd-current@freebsd.org Subject: Re: mmap bug? Message-ID: <20050731201858.GC1052@gothmog.gr> In-Reply-To: <84dead720507311115290f0140@mail.gmail.com> References: <20050731141801.GA49300@gothmog.gr> <84dead7205073108564f71f1ab@mail.gmail.com> <20050731160853.GC49839@gothmog.gr> <84dead720507311115290f0140@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2005-07-31 23:45, Joseph Koshy <joseph.koshy@gmail.com> wrote: > gk> That's something I didn't test. No, the 'extra' data > gk> disappears. > > So the 'extra' data isn't reaching the FS and is probably > being served up from a cached VM data the second time your > test program ran. > > This is still a bug though: the mmap(2) manual page > says: > ... > If len is not a multiple of > the page-size, the mapped region may extend past the > specified range. Any such extension beyond the end of the > mapped object will be zero-filled. > ... > > We are clearly not doing the zero-filling. The mapping is allocated as MAP_SHARED, so when I unmap() it from a process that has attached to the specific object/file/whatever that is, it shouldn't be zeroed. The bug seems to be elsewhere, namely to the fact that the filesystem code never realizes the file has changed size after I use mmap() to map a region beyond its current size and write past its current end.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050731201858.GC1052>