Subject: Re: nfs invalidates lose pte dirty bits
From: Trond Myklebust <trond.myklebust@fys.uio.no>
To: Andrea Arcangeli <andrea@suse.de>
Cc: Andrew Morton <akpm@osdl.org>, linux-kernel@vger.kernel.org
In-Reply-To: <20051223151711.GA9576@opteron.random>
References: <20051222175550.GT9576@opteron.random>
	 <1135294250.3685.16.camel@lade.trondhjem.org>
	 <20051223023603.GY9576@opteron.random>
	 <1135327315.8167.11.camel@lade.trondhjem.org>
	 <20051223151711.GA9576@opteron.random>
Content-Type: text/plain
Date: Fri, 23 Dec 2005 22:02:59 +0100
Message-Id: <1135371779.8555.7.camel@lade.trondhjem.org>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 1089
Lines: 24

On Fri, 2005-12-23 at 16:17 +0100, Andrea Arcangeli wrote:
> > However if the user is doing mmap writes while the file is in the
> > process of being modified on the server, then they are doing something
> > wrong anyway. The small race between nfs_sync_mapping() and
> > invalidate_inode_pages2() is the least of their problems.
> 
> I'm talking about spurious revalidates, I don't think the testcase I'm
> dealing with is really needing an invalidate, it's a spurious one
> (perhaps triggered by flock), but I'm lucky it's single threaded so
> current fix will work for them.

We should perhaps think of setting up an
"unmap_write_dirty_and_invalidate" helper in order to deal with this
sort of race. As long as we have to first unmap all the pages, then
write the dirty ones, then invalidate them, we will be open to races.

Cheers,
  Trond

-
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/