Re: [patch] mm: mremap correct rmap accounting

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

Hugh Dickins wrote:
> But there is a change which I now think you do need to make,
> for 2.6.21 - let it not distract attention from the pagecount
> correctness issue we've been discussing so far.  Something I
> should have noticed when I first looked at your clever use of
> the ZERO_PAGE, but have only noticed now.  Doesn't it clash
> with the clever use of the ZERO_PAGE when reading /dev/zero
> (see read_zero_pagealigned in drivers/char/mem.c)?
> 
> Consider two PROT_READ|PROT_WRITE,MAP_PRIVATE mappings of a
> four-page hole in a XIP file.  One of them just readfaults the
> four pages in (and is given ZERO_PAGE for each), the other has
> four pages read from /dev/zero into it (which also maps the
> ZERO_PAGE into its four ptes).
> 
> Then imagine that non-zero data is written to the first page of
> that hole, by a write syscall, or through a PROT_WRITE,MAP_SHARED
> mapping.  __xip_unmap will replace the first ZERO_PAGE in each of
> the MAP_PRIVATE mappings by the new non-zero data page.  Which is
> correct for the first mapping which just did readfaults, but wrong
> for the second mapping which has overwritten by reading /dev/zero
> - those pages ought to remain zeroed, never seeing the later data.
Nasty. I got your point now, but as far as I can see we're still in-spec:

MAP_PRIVATE
Create a private copy-on-write mapping.  Stores to the region do not
affect the original file.  It is unspecified whether changes made to
the file after the mmap call are visible in the mapped region.

A fix could be to use my own empty page instead of the ZERO_PAGE for 
xip. At least we have different behavior with/without xip here, 
therefore I agree that this requires fixing.

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>