Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757462Ab2F0XeL (ORCPT ); Wed, 27 Jun 2012 19:34:11 -0400 Received: from mail-wi0-f172.google.com ([209.85.212.172]:62052 "EHLO mail-wi0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751910Ab2F0XeH (ORCPT ); Wed, 27 Jun 2012 19:34:07 -0400 MIME-Version: 1.0 In-Reply-To: References: <20120627211540.459910855@chello.nl> <20120627212831.137126018@chello.nl> <1340838154.10063.86.camel@twins> <1340838807.10063.90.camel@twins> From: Linus Torvalds Date: Wed, 27 Jun 2012 16:33:44 -0700 X-Google-Sender-Auth: JXEuFwCbBn-iliBXoaE5K5a4zfc Message-ID: Subject: Re: [PATCH 08/20] mm: Optimize fullmm TLB flushing To: Peter Zijlstra Cc: 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 , Catalin Marinas , Chris Metcalf , Martin Schwidefsky , Tony Luck , Paul Mundt , Jeff Dike , Richard Weinberger , Ralf Baechle , Kyle McMartin , James Bottomley , Chris Zankel Content-Type: text/plain; charset=ISO-8859-1 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1812 Lines: 37 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. Taking a user address from the BTB is just one example. Speculative memory accesses might happen after a mis-predicted branch, where we test a pointer against NULL, and after the branch we access it. So doing a speculative TLB walk of the NULL address would not necessarily even be unusual. Obviously normally nothing is actually mapped there, but these kinds of things can *easily* result in the page tables themselves being cached, even if the final page doesn't exist. Also, all of this obviously depends on how aggressive the speculation is. It's entirely possible that effects like these are really hard to see in practice, and you'll almost never hit it. But stale TLB contents (or stale page directory caches) are *really* nasty when they do happen, and almost impossible to debug. So we want to be insanely anal in this area. Linus -- 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/