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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 

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 [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/
[Index of Archives]     [Kernel Newbies]     [Netfilter]     [Bugtraq]     [Photo]     [Stuff]     [Gimp]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Video 4 Linux]     [Linux for the blind]     [Linux Resources]
  Powered by Linux