Re: [patch] mm: mremap correct rmap accounting

[Carsten Otte <cotte@de.ibm.com>]

Hugh Dickins wrote:
 > I agree that last sentence _appears_ to give you a let out.  I
 > believe its intention is to address the case where one page has been
 > faulted in and written to by the app, the next page is unfaulted
 > then modified by some other means and then faulted into the app for
 > the first time:
 > that page will contain the mods made to the underlying object, even
 > though they were made after the private copy of the previous page
 > was taken (which copy should never show later mods to the underlying
 > object).
 > Whereas if the mapping were mmap'ed with MAP_LOCKED (or mlocked),
 > all pages would be faulted in immediately, and subsequent mods to
 > the underlying object never seen at all.
I see. Makes sense to interpret the spec that way.

 > Whatever the wording, I don't know of any application which is happy
 > for the modifications it makes to a MAP_PRIVATE mapping to disappear
 > without warning - except when it actually asks for that behaviour by
 > calling madvise(start, len, MADV_DONTNEED).
I am not happy with any visibility of xip to userland via filesystem 
syscalls. It is supposed to be transparent for userspace.

 > Yes, if your testing shows that it really does behave as I suspect.
It does indeed. My little test program shows it:
- ext2 in regular operation:
current state: read-faulted sparse mappings
content of area1:
content of area2:
current state: read zero into area1
content of area1:
content of area2:
current state: write data via sys_write
content of area1:
content of area2: this change was written using sys_write

- ext with xip:
current state: read-faulted sparse mappings
content of area1:
content of area2:
current state: read zero into area1
content of area1:
content of area2:
current state: write data via sys_write
content of area1: this change was written using sys_write
content of area2: this change was written using sys_write

That proves your suspicion. I will submit a fix. Thank you for 
pointing me at it.

Carsten

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>