Re: msync(2)

[Matthew Mondor <mm_lists%pulsar-zone.net@localhost>]

On Mon, 22 Feb 2010 17:36:01 -0500 (EST)
der Mouse <mouse%Rodents-Montreal.ORG@localhost> wrote:

> > I have a question reguarding mmap(2)ed files which are modified.
> 
> Modified through the mmapped memory, I take it you mean?  (They can
> also be modified through the filesystem interface, and most of the
> interesting questions hinge on having two different access paths to a
> single set of bytes.)

Right, modified via the mapped memory.

> > After reading the manual page of msync(2), I have the impression that
> > if invoked with the MS_SYNC flag, it should be safe enough not to
> > need a further fdatasync(2)/fsync_range(2) call afterwards?
> 
> That's my own impression too - indeed, it's not clear to me that
> fdatasync has any bearing; it's not clear to me that an mmapped memory
> range is "data associated with" any file descriptor.  It's at least as
> fd-specific as the fsync() you mention below.

Indeed, and if I remember after mmap(2) a descriptor can be closed
before doing operations on the file, so it's no longer even attached to
an FD per say, I think.

> Is that how the current implementation works?  I don't know.

I have no idea, but that's why I used tech-kern over tech-userlevel for
these questions, as there probably are some around familiar with the
implementation :)

> > Also, I am auditing an application which seems to modify mmaped files
> > but which does not use msync(2) at all (and I can see that an older
> > fsync(2) call was used, but is now commented out).  Should this be
> > considered a bug?
> 
> In my opinion?  No, unless access to the same files via filesystem
> methods needs to be coherent with the mmap()ped view.  Maybe not even
> then, depending on things you haven't told us (eg, how restricted the
> target OS scope for the thing is - some things that are bugs if it's
> supposed to run on anything POSIX may not be fine if, say, anything
> except SunOS 4.1.1 on a SPARCstation-4 is out of scope).

The application in question doesn't use mmap() for sharing in this case,
but probably for the convenient random-access performance (to maintain
a bitmap file).  I've seen inconsistent data after a crash a few times
when using WAPBL, but not with softdep.  That said, the application
could very well be using mmap unsafely...

Thanks,
-- 
Matt