[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
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
> > 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...
Main Index |
Thread Index |