Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760243Ab2J2RGl (ORCPT ); Mon, 29 Oct 2012 13:06:41 -0400 Received: from mail-we0-f174.google.com ([74.125.82.174]:37344 "EHLO mail-we0-f174.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1760223Ab2J2RGh (ORCPT ); Mon, 29 Oct 2012 13:06:37 -0400 MIME-Version: 1.0 In-Reply-To: <20121029165705.GA4693@x1.osrc.amd.com> References: <508A0A0D.4090001@redhat.com> <508A8D31.9000106@redhat.com> <20121026132601.GC9886@gmail.com> <20121026144502.6e94643e@dull> <20121026221254.7d32c8bf@pyramind.ukuu.org.uk> <508BE459.2080406@redhat.com> <20121029165705.GA4693@x1.osrc.amd.com> From: Linus Torvalds Date: Mon, 29 Oct 2012 10:06:15 -0700 X-Google-Sender-Auth: dQKG_r-BrpOFIOk5hcl2SV00K5k Message-ID: Subject: Re: [PATCH 2/3] x86,mm: drop TLB flush from ptep_set_access_flags To: Borislav Petkov , Rik van Riel , Alan Cox , Ingo Molnar , Andi Kleen , Michel Lespinasse , Peter Zijlstra , Andrea Arcangeli , Mel Gorman , Johannes Weiner , Thomas Gleixner , Andrew Morton , linux-kernel@vger.kernel.org, linux-mm@kvack.org, florian@openwrt.org, Borislav Petkov 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: 1676 Lines: 39 On Mon, Oct 29, 2012 at 9:57 AM, Borislav Petkov wrote: > > On current AMD64 processors, Can you verify that this is true for older cpu's too (ie the old pre-64-bit ones, say K6 and original Athlon)? > This is done because a table entry is allowed > to be upgraded (by marking it as present Well, that was traditionally solved by not caching not-present entries at all. Which can be a problem for some things (prefetch of NULL etc), so caching and then re-checking on faults is potentially the correct thing, but I'm just mentioning it because it might not be much of an argument for older microarchitectures.. >, or by removing its write, > execute or supervisor restrictions) without explicitly maintaining TLB > coherency. Such an upgrade will be found when the table is re-walked, > which resolves the fault. .. but this is obviously what we're interested in. And since AMD has documented it (as well as Intel), I have this strong suspicion that operating systems have traditionally relied on this behavior. I don't remember the test coverage details from my Transmeta days, and while I certainly saw the page table walker, it wasn't my code. My gut feel is that this is likely something x86 just always does (because it's the right thing to do to keep things simple for software), but getting explicit confirmation about older AMD cpu's would definitely be good. 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/