Re: msync(2)

[der Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> 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.)

> 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.

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

> And how about the metadata?  Would sync(2) be the only true way to
> ensure it's synchronized (considering fsync(2) seems fd-specific)?

Good question.  I have nothing useful to say there.

> 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 ASCII                             Mouse
\ / Ribbon Campaign
 X  Against HTML                mouse%rodents-montreal.org@localhost
/ \ Email!           7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B