Re: msync() behaviour broken for MS_ASYNC, revert patch?
From: Linus Torvalds
Date: Fri Feb 10 2006 - 17:45:24 EST
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 majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/