From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate4.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0VDpSH7081224 for ; Wed, 31 Jan 2007 13:51:28 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0VDpSD81564778 for ; Wed, 31 Jan 2007 14:51:28 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0VDpRsS018235 for ; Wed, 31 Jan 2007 14:51:28 +0100 Message-ID: <45C09EDF.4060606@de.ibm.com> Date: Wed, 31 Jan 2007 14:51:27 +0100 From: Carsten Otte Reply-To: carsteno@de.ibm.com MIME-Version: 1.0 Subject: Re: [patch] mm: mremap correct rmap accounting References: <45B61967.5000302@yahoo.com.au> <45BD6A7B.7070501@yahoo.com.au> <45BF68A4.5070002@de.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-linux-mm@kvack.org Return-Path: To: Hugh Dickins Cc: Carsten Otte , Linus Torvalds , Nick Piggin , Linux Memory Management , Andrew Morton , Ralf Baechle List-ID: Hugh Dickins wrote: > I think it's now clear that XIP won't be impacted at all by my > ZERO_PAGE(0) change, and that's the patch Linus should put in > for 2.6.20 (given how much he disliked Nick's patch to maintain > the different zeropage counts across mremap move). Ah, good, > that's now gone into his tree since last I looked. Good to know this issue is solved. Thank you. > 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. Wait a second, I fail to see why those pages in the second mapping should remain zeroed and never see the later data; they do reflect the file content that was mmap()ed there correctly at all times. I would expect this behavior, and would expect to see both mappings reflect this data. Am I missing something? > Or have I got it wrong? A simple test should show. The test is simple indeed, will do that - and compare page cache backed file behavior with xip file. 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: email@kvack.org