Re: Possible problems with mmap/munmap on FreeBSD ...

From: Alan Cox (alc_at_cs.rice.edu)
Date: 03/30/05

  • Next message: Marc Olzheim: "Making gcc "-Wformat" more verbose" 
    Date: Wed, 30 Mar 2005 11:36:22 -0600
To: Richard Sharpe <rsharpe@richardsharpe.com>, freebsd-hackers@FreeBSD.ORG, alc@FreeBSD.ORG

    On Tue, Mar 29, 2005 at 09:18:32PM -0500, David Schultz wrote:
    > On Tue, Mar 29, 2005, Richard Sharpe wrote:
    > > Hi,
    > >
    > > I am having some problems with the tdb package on FreeBSD 4.6.2 and 4.10.
    > >
    > > One of the things the above package does is:
    > >
    > > mmap the tdb file to a region of memory
    > > store stuff in the region (memmov etc).
    > > when it needs to extend the size of the region {
    > > munmap the region
    > > write data at the end of the file
    > > mmap the region again with a larger size
    > > }
    > >
    > > What I am seeing is that after the munmap the data written to the region
    > > is gone.
    > >
    > > However, if I insert an msync before the munmap, everything is nicely
    > > coherent. This seems odd (in the sense that it works without the msync
    > > under Linux).
    > >
    > > The region is mmapped with:
    > >
    > > mmap(NULL, tdb->map_size,
    > > PROT_READ|(tdb->read_only? 0:PROT_WRITE),
    > > MAP_SHARED|MAP_FILE, tdb->fd, 0);
    > >
    > > What I notice is that all the calls to mmap return the same address.
    > >
    > > A careful reading of the man pages for mmap and munmap does not suggest
    > > that I am doing anything wrong.
    > >
    > > Is it possible that FreeBSD is deferring flushing the dirty data, and then
    > > forgets to do it when the same starting address is used etc?
    >
    > It looks like all of the underlying pages are getting invalidated
    > in vm_object_page_remove(). This is clearly the right thing to do
    > for private mappings, but it seems wrong for shared mappings.
    > Perhaps Alan has some insight.

    Hmm. In this code path we don't call vm_object_page_remove() on
    vnode-backed objects, only default/swap-backed objects that have no
    other mappings that reference them.

    Regards,
    Alan
    _______________________________________________
    freebsd-hackers@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
    To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org"

  • Next message: Marc Olzheim: "Making gcc "-Wformat" more verbose"

    Relevant Pages

    • Re: Possible problems with mmap/munmap on FreeBSD ...
      ... >> mmap the region again with a larger size ... >> What I am seeing is that after the munmap the data written to the region ... compares shows expected behavior ...
      (freebsd-hackers)
    • Re: [PATCH 3/5] perf_counter: rework ioctl()s
      ... Paul Mackerras wrote: ... then reopen, and mmap again. ... That is, you don't have to munmap before close, but you do have to do ... both close and munmap to destroy the counter. ...
      (Linux-Kernel)
    • Possible problems with mmap/munmap on FreeBSD ...
      ... I am having some problems with the tdb package on FreeBSD 4.6.2 and 4.10. ... mmap the tdb file to a region of memory ... mmap the region again with a larger size ... What I am seeing is that after the munmap the data written to the region ...
      (freebsd-hackers)
    • Re: Possible problems with mmap/munmap on FreeBSD ...
      ... > mmap the tdb file to a region of memory ... > mmap the region again with a larger size ... > What I am seeing is that after the munmap the data written to the region ... for private mappings, but it seems wrong for shared mappings. ...
      (freebsd-hackers)
    • Re: NFS: msync required for data writes to server?
      ... > is not issued before the munmap. ... In the case where the page was dirtied by mmap and was then unmapped (via ... the page will be marked dirty in pagecache ... send the line "unsubscribe linux-kernel" in ...
      (Linux-Kernel)