From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 30 Jan 2008 17:27:37 -0800 (PST) From: Christoph Lameter Subject: Re: [kvm-devel] [patch 1/6] mmu_notifier: Core code In-Reply-To: <20080131001258.GD7185@v2.random> Message-ID: References: <20080130022909.677301714@sgi.com> <20080130022944.236370194@sgi.com> <20080130153749.GN7233@v2.random> <20080130155306.GA13746@sgi.com> <20080130222035.GX26420@sgi.com> <20080130233803.GB7185@v2.random> <20080131001258.GD7185@v2.random> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-linux-mm@kvack.org Return-Path: To: Andrea Arcangeli Cc: Nick Piggin , Peter Zijlstra , linux-mm@kvack.org, Benjamin Herrenschmidt , Jack Steiner , linux-kernel@vger.kernel.org, Avi Kivity , kvm-devel@lists.sourceforge.net, daniel.blueman@quadrics.com, Robin Holt , Hugh Dickins List-ID: On Thu, 31 Jan 2008, Andrea Arcangeli wrote: > > Hmmmm.. exit_mmap is only called when the last reference is removed > > against the mm right? So no tasks are running anymore. No pages are left. > > Do we need to serialize at all for mmu_notifier_release? > > KVM sure doesn't need any locking there. I thought somebody had to > possibly take a pin on the "mm_count" and pretend to call > mmu_notifier_register at will until mmdrop was finally called, in a > out of order fashion given mmu_notifier_release was implemented like > if the list could change from under it. Note mmdrop != mmput. mmput > and in turn mm_users is the serialization point if you prefer to drop > all locking from _release. Nobody must ever attempt a mmu_notifier_* > after calling mmput for that mm. That should be enough to be > safe. I'm fine either ways... exit_mmap (where we call invalidate_all() and release()) is called when mm_users == 0: void mmput(struct mm_struct *mm) { might_sleep(); if (atomic_dec_and_test(&mm->mm_users)) { exit_aio(mm); exit_mmap(mm); if (!list_empty(&mm->mmlist)) { spin_lock(&mmlist_lock); list_del(&mm->mmlist); spin_unlock(&mmlist_lock); } put_swap_token(mm); mmdrop(mm); } } EXPORT_SYMBOL_GPL(mmput); So there is only a single thread executing at the time when invalidate_all() is called from exit_mmap(). Then we drop the pages, and the page tables. After the page tables we call the ->release method and then remove the vmas. So even dropping off the mmu_notifier chain in invalidate_all() could be done without an issue and without locking. Trouble is if other callbacks attempt the same. Do we need to support the removal from the mmu_notifier list in invalidate_range()? -- 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