Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755077AbXKLRDO (ORCPT ); Mon, 12 Nov 2007 12:03:14 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1758338AbXKLRCo (ORCPT ); Mon, 12 Nov 2007 12:02:44 -0500 Received: from extu-mxob-2.symantec.com ([216.10.194.135]:41713 "EHLO extu-mxob-2.symantec.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753530AbXKLRCm (ORCPT ); Mon, 12 Nov 2007 12:02:42 -0500 Date: Mon, 12 Nov 2007 17:01:51 +0000 (GMT) From: Hugh Dickins X-X-Sender: hugh@blonde.wat.veritas.com To: Erez Zadok cc: Dave Hansen , Pekka Enberg , Ryan Finnie , Andrew Morton , linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org, cjwatson@ubuntu.com, linux-mm@kvack.org Subject: Re: msync(2) bug(?), returns AOP_WRITEPAGE_ACTIVATE to userland In-Reply-To: <200711090605.lA965B1S024066@agora.fsl.cs.sunysb.edu> Message-ID: References: <200711090605.lA965B1S024066@agora.fsl.cs.sunysb.edu> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1623 Lines: 35 On Fri, 9 Nov 2007, Erez Zadok wrote: > In message , Hugh Dickins writes: > > > Three, I believe you need to add a flush_dcache_page(lower_page) > > after the copy_highpage(lower_page): some architectures will need > > that to see the new data if they have lower_page mapped (though I > > expect it's anyway shaky ground to be accessing through the lower > > mount at the same time as modifying through the upper). > > OK. While looking into something else entirely, I realize that _here_ you are missing a SetPageUptodate(lower_page): should go in after the flush_dcache_page(lower_page) I'm suggesting. (Nick would argue for some kind of barrier there too, but I don't think unionfs has a special need to be ahead of the pack on that issue.) Think about it: when find_or_create_page has created a fresh page in the cache, and you've just done copy_highpage to put the data into it, you now need to mark it as Uptodate: otherwise a subsequent vfs_read or whatever on the lower level will find that page !Uptodate and read stale data back from disk instead of what you just copied in, unless its dirtiness has got it written back to disk meanwhile. Odd that that hasn't been noticed at all: I guess it may be hard to get testing to reclaim lower/upper pages in such a way as to test out such paths thoroughly. Hugh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/