Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1762130AbYB1ALl (ORCPT ); Wed, 27 Feb 2008 19:11:41 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932068AbYB1ALP (ORCPT ); Wed, 27 Feb 2008 19:11:15 -0500 Received: from host36-195-149-62.serverdedicati.aruba.it ([62.149.195.36]:33508 "EHLO mx.cpushare.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760095AbYB1ALO (ORCPT ); Wed, 27 Feb 2008 19:11:14 -0500 Date: Thu, 28 Feb 2008 01:11:04 +0100 From: Andrea Arcangeli To: Christoph Lameter Cc: Nick Piggin , akpm@linux-foundation.org, Robin Holt , Avi Kivity , Izik Eidus , kvm-devel@lists.sourceforge.net, Peter Zijlstra , general@lists.openfabrics.org, Steve Wise , Roland Dreier , Kanoj Sarcar , steiner@sgi.com, linux-kernel@vger.kernel.org, linux-mm@kvack.org, daniel.blueman@quadrics.com Subject: Re: [patch 2/6] mmu_notifier: Callbacks to invalidate address ranges Message-ID: <20080228001104.GB8091@v2.random> References: <20080215064859.384203497@sgi.com> <20080215064932.620773824@sgi.com> <200802201008.49933.nickpiggin@yahoo.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1340 Lines: 29 On Wed, Feb 27, 2008 at 02:35:59PM -0800, Christoph Lameter wrote: > Could you be specific? This refers to page migration? Hmmm... Guess we If the reader schedule, the synchronize_rcu will return in the other cpu and the objects in the list will be freed and overwritten, and when the task is scheduled back in, it'll follow dangling pointers... You can't use RCU if you want any of your invalidate methods to schedule. Otherwise it's like having zero locking. > 2. Not handle file backed mappings (XPmem could work mostly in such a > config) IMHO that fits under your definition of "hacking something in now and then having to modify it later". > 3. Keep the refcount elevated until pages are freed in another execution > context. Page refcount is not enough (the mmu_notifier_release will run in another cpu the moment after i_mmap_lock is unlocked) but mm_users may prevent us to change the i_mmap_lock to a mutex, but it'll slowdown truncate as it'll have to drop the lock and restart the radix tree walk every time so a change like this better fits as a separate CONFIG_XPMEM IMHO. -- 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/