Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S935152AbZDBHFU (ORCPT ); Thu, 2 Apr 2009 03:05:20 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1762349AbZDBHD1 (ORCPT ); Thu, 2 Apr 2009 03:03:27 -0400 Received: from sous-sol.org ([216.99.217.87]:49088 "EHLO sequoia.sous-sol.org" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751539AbZDBHD0 (ORCPT ); Thu, 2 Apr 2009 03:03:26 -0400 Date: Wed, 1 Apr 2009 23:57:40 -0700 From: Chris Wright To: linux-kernel@vger.kernel.org, stable@kernel.org Cc: "Theodore Ts'o" , Zwane Mwaikambo , Eugene Teo , Justin Forbes , Domenico Andreoli , Chris Wedgwood , Jake Edge , Randy Dunlap , Michael Krufky , alan@lxorguk.ukuu.org.uk, Chuck Ebbert , Dave Jones , Chuck Wolber , akpm@linux-foundation.org, torvalds@linux-foundation.org, Willy Tarreau , Rodrigo Rubira Branco , davem@davemloft.net Subject: [PATCH 46/45] sparc64: Fix MM refcount check in smp_flush_tlb_pending(). Message-ID: <20090402065740.GB18394@sequoia.sous-sol.org> References: <20090331231045.719396245@sous-sol.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20090331231045.719396245@sous-sol.org> User-Agent: Mutt/1.5.18 (2008-05-17) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3204 Lines: 73 -stable review patch. If anyone has any objections, please let us know. --------------------- From: David S. Miller [ Upstream commit f9384d41c02408dd404aa64d66d0ef38adcf6479 ] As explained by Benjamin Herrenschmidt: > CPU 0 is running the context, task->mm == task->active_mm == your > context. The CPU is in userspace happily churning things. > > CPU 1 used to run it, not anymore, it's now running fancyfsd which > is a kernel thread, but current->active_mm still points to that > same context. > > Because there's only one "real" user, mm_users is 1 (but mm_count is > elevated, it's just that the presence on CPU 1 as active_mm has no > effect on mm_count(). > > At this point, fancyfsd decides to invalidate a mapping currently mapped > by that context, for example because a networked file has changed > remotely or something like that, using unmap_mapping_ranges(). > > So CPU 1 goes into the zapping code, which eventually ends up calling > flush_tlb_pending(). Your test will succeed, as current->active_mm is > indeed the target mm for the flush, and mm_users is indeed 1. So you > will -not- send an IPI to the other CPU, and CPU 0 will continue happily > accessing the pages that should have been unmapped. To fix this problem, check ->mm instead of ->active_mm, and this means: > So if you test current->mm, you effectively account for mm_users == 1, > so the only way the mm can be active on another processor is as a lazy > mm for a kernel thread. So your test should work properly as long > as you don't have a HW that will do speculative TLB reloads into the > TLB on that other CPU (and even if you do, you flush-on-switch-in should > get rid of any crap here). And therefore we should be OK. Signed-off-by: David S. Miller Signed-off-by: Chris Wright --- arch/sparc/kernel/smp_64.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/arch/sparc/kernel/smp_64.c +++ b/arch/sparc/kernel/smp_64.c @@ -1031,7 +1031,7 @@ void smp_fetch_global_regs(void) * If the address space is non-shared (ie. mm->count == 1) we avoid * cross calls when we want to flush the currently running process's * tlb state. This is done by clearing all cpu bits except the current - * processor's in current->active_mm->cpu_vm_mask and performing the + * processor's in current->mm->cpu_vm_mask and performing the * flush locally only. This will force any subsequent cpus which run * this task to flush the context from the local tlb if the process * migrates to another cpu (again). @@ -1074,7 +1074,7 @@ void smp_flush_tlb_pending(struct mm_str u32 ctx = CTX_HWBITS(mm->context); int cpu = get_cpu(); - if (mm == current->active_mm && atomic_read(&mm->mm_users) == 1) + if (mm == current->mm && atomic_read(&mm->mm_users) == 1) mm->cpu_vm_mask = cpumask_of_cpu(cpu); else smp_cross_call_masked(&xcall_flush_tlb_pending, -- 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/