From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 31 May 2006 16:09:06 +0100 (BST) From: Hugh Dickins Subject: Re: [rfc][patch] remove racy sync_page? In-Reply-To: <447D9D9C.1030602@yahoo.com.au> Message-ID: References: <447AC011.8050708@yahoo.com.au> <20060529121556.349863b8.akpm@osdl.org> <447B8CE6.5000208@yahoo.com.au> <20060529183201.0e8173bc.akpm@osdl.org> <447BB3FD.1070707@yahoo.com.au> <20060529201444.cd89e0d8.akpm@osdl.org> <20060530090549.GF4199@suse.de> <447D9D9C.1030602@yahoo.com.au> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Nick Piggin Cc: Jens Axboe , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, mason@suse.com, andrea@suse.de, torvalds@osdl.org List-ID: On Wed, 31 May 2006, Nick Piggin wrote: > Jens Axboe wrote: > > > > Maybe I'm being dense, but I don't see a problem there. You _should_ > > call the new mapping sync page if it has been migrated. > > But can some other thread calling lock_page first find the old mapping, > and then run its ->sync_page which finds the new mapping? While it may > not matter for anyone in-tree, it does break the API so it would be > better to either fix it or rip it out than be silently buggy. Splicing a page from one mapping to another is rather worrying/exciting, but it does look safely done to me. remove_mapping checks page_count while page lock and old mapping->tree_lock are held, and gives up if anyone else has an interest in the page. And we already know it's unsafe to lock_page without holding a reference to the page, don't we? Hugh -- 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