Re: msync() behaviour broken for MS_ASYNC, revert patch?

From: Trond Myklebust
Date: Fri Feb 10 2006 - 16:53:44 EST


On Fri, 2006-02-10 at 13:10 -0800, Linus Torvalds wrote:
> This historical meaning as far as I can tell, for MS_INVALIDATE really
> _forgets_ the old mmap'ped contents in a non-coherent system.
>
> Quoting from a UNIX man-page (as found by google):
>
> ...
>
> If flags is MS_INVALIDATE, the function synchronizes the
> contents of the memory region to match the current file
> contents.
>
> o All writes to the mapped portion of the file made
> prior to the call are visible by subsequent read
> references to the mapped memory region.
>
> o All write references prior to the call, by any pro-
> cess, to memory regions mapped to the same portion of
> the file using MAP_SHARED, are visible by read refer-
> ences to the region.

The Single Unix Spec appears to have a very different interpretation.
See http://www.opengroup.org/onlinepubs/009695399/toc.htm

When MS_ASYNC is specified, msync() shall return immediately
once all the write operations are initiated or queued for
servicing; when MS_SYNC is specified, msync() shall not return
until all write operations are completed as defined for
synchronized I/O data integrity completion. Either MS_ASYNC or
MS_SYNC is specified, but not both.

When MS_INVALIDATE is specified, msync() shall invalidate all
cached copies of mapped data that are inconsistent with the
permanent storage locations such that subsequent references
shall obtain data that was consistent with the permanent storage
locations sometime between the call to msync() and the first
subsequent memory reference to the data.

If msync() causes any write to a file, the file's st_ctime and
st_mtime fields shall be marked for update.

Cheers,
Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/