From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from psmtp.com (na3sys010amx136.postini.com [74.125.245.136]) by kanga.kvack.org (Postfix) with SMTP id 740DC6B005C for ; Thu, 28 Jun 2012 05:19:58 -0400 (EDT) Date: Thu, 28 Jun 2012 10:16:27 +0100 From: Catalin Marinas Subject: Re: [PATCH 08/20] mm: Optimize fullmm TLB flushing Message-ID: <20120628091627.GB8573@arm.com> References: <20120627211540.459910855@chello.nl> <20120627212831.137126018@chello.nl> <1340838154.10063.86.camel@twins> <1340838807.10063.90.camel@twins> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: Content-Language: en-US Sender: owner-linux-mm@kvack.org List-ID: To: Linus Torvalds Cc: Peter Zijlstra , "linux-kernel@vger.kernel.org" , "linux-arch@vger.kernel.org" , "linux-mm@kvack.org" , Thomas Gleixner , Ingo Molnar , "akpm@linux-foundation.org" , Rik van Riel , Hugh Dickins , Mel Gorman , Nick Piggin , Alex Shi , "Nikunj A. Dadhania" , Konrad Rzeszutek Wilk , Benjamin Herrenschmidt , David Miller , Russell King , Chris Metcalf , Martin Schwidefsky , Tony Luck , Paul Mundt , Jeff Dike , Richard Weinberger , Ralf Baechle , Kyle McMartin , James Bottomley , Chris Zankel On Thu, Jun 28, 2012 at 12:33:44AM +0100, Linus Torvalds wrote: > On Wed, Jun 27, 2012 at 4:23 PM, Linus Torvalds > wrote: > > But the branch prediction tables are obviously just predictions, and > > they easily contain user addresses etc in them. So the kernel may well > > end up speculatively doing a TLB fill on a user access. > > That should be ".. on a user *address*", hopefully that was clear from > the context, if not from the text. > > IOW, the point I'm trying to make is that even if there are zero > *actual* accesses of user space (because user space is dead, and the > kernel hopefully does no "get_user()/put_user()" stuff at this point > any more), the CPU may speculatively use user addresses for the > bog-standard kernel addresses that happen. That's definitely an issue on ARM and it was hit on older kernels. Basically ARM processors can cache any page translation level in the TLB. We need to make sure that no page entry at any level (either cached in the TLB or not) points to an invalid next level table (hence the TLB shootdown). For example, in cases like free_pgd_range(), if the cached pgd entry points to an already freed pud/pmd table (pgd_clear is not enough) it may walk the page tables speculatively cache another entry in the TLB. Depending on the random data it reads from an old table page, it may find a global entry (it's just a bit in the pte) which is not tagged with an ASID (application specific id). A latter flush_tlb_mm() only flushes the current ASID and doesn't touch global entries (used only by kernel mappings). So we end up with global TLB entry in user space that overrides any other application mapping. -- Catalin -- 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