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

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

 


On Fri, 10 Feb 2006, Trond Myklebust wrote:
> 
> The Single Unix Spec appears to have a very different interpretation.

Hmm. Very different wording, but same meaning, I think.

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

Again, this says that the _mapping_ is invalidated, and should match 
persistent storage.

Any dirty bits in the mapping (ie anything that hasn't been msync'ed) 
should be made persistent with permanent storage. Again, that is entirely 
consistent with just throwing the mmap'ed page away (dirty state and all) 
in a non-coherent environment.

I don't think we really have any modern Unixes with non-coherent mmap's 
(although HP-UX used to be that way for a _loong_ time). But in the 
timeframe that was written, it was probably still an issue.

Now, in a _coherent_ environment (like Linux) it should probably be a 
no-op, since the mapping is always consistent with storage (where 
"storage" doesn't actyally mean "disk", but the virtual file underneath 
the mapping).

If the page is dirty in the page tables, we've modified the page contents 
in the backing store (since we share it). But it would be consistent with 
the standard wrt MS_INVALIDATE (but totally insane) to throw the dirty 
state - and the page cache page - away if the page cache is clean.

The point being that a truly portable app can't really know what the hell 
it does - it hass to know whether mmap is coherent or not, and if mmap is 
coherent, then MS_INVALIDATE should _probably_ be a no-op.

(Which it is under modern Linux - MS_INVALIDATE is effectively a no-op, 
except we still have the old check that you can't invalidate a locked 
area. It _used_ to actually clear the page tables)

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