Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp4447121imu; Mon, 12 Nov 2018 11:08:46 -0800 (PST) X-Google-Smtp-Source: AJdET5dhMWXU/Mw5wGcnjO3zBS10DJq3YJbhbJx4g1j1N62xv5vXpcv5ORiIbRkc9WnBflBI03Id X-Received: by 2002:a63:c42:: with SMTP id 2mr1874870pgm.372.1542049726697; Mon, 12 Nov 2018 11:08:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1542049726; cv=none; d=google.com; s=arc-20160816; b=lopO1jrkCsvJXZCGKbcQJByHhFvNtojv47vS1N8pGyQHoUnnzS8xz/4ojI0eyyH+M5 Thw0U4NjOUN56s7gu5FcsKGmk0VnOxVh/oTUNZaG9Y1WFaAReL6uDzIytWTrfVeoyMOt lFTMzP0JvLxQBCe0GylFCve+TUoSa6eiWjOFtycFnBH8Jzg9glXhqXHIZTqTHloCjKZX TjfOfrQ6uUGRU+H7SFJ2McdlsETN+enKesEv2WXhd+6vOpNHRcFUO7y+goVwwBw2X0ON nLfMkhO2tOWla10bug+yGKoR62fPyNm7tAShq++EfEY0liCbx+yemS8hH138Y4/UDIis H31Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:autocrypt:openpgp:from:references:cc:to:subject; bh=V75M9mH8FSoRBFAX4SlQjwz/Ot6rLQRjZEwQVYqP0a0=; b=GQFKhrkiI19Ab++LA86EfqyIKieE+DtBgxTSoIdE2wuS8/CtGgByIpp1FWGioNcHq5 izHZZm3026WqeC7ol2beOjcQDS+5T09EXXDgGLdkLP8153q7/Gdooq0ccgdRuAndsUga rRppEW1OE8gH7lgr52mJf9Pijgky80Ks1kUGPWItl2J7eZF3Qw2aVApLLEM0kIw3AS6g 1EYfHGzRvp+4f4oy18fih773X+1uKcUHPb53J2BSSk8yVCF7v4Ywpo2A66LJBHUFt3Rt 65KRHvzWPYY5g9Lqr/8su7HGrh2wLaR6fxfIIONQkCL+hObkjTkkdQQF7UrLt60eFfce HZXQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id f38si16922954pgf.206.2018.11.12.11.08.31; Mon, 12 Nov 2018 11:08:46 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=intel.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726056AbeKMFC2 (ORCPT + 99 others); Tue, 13 Nov 2018 00:02:28 -0500 Received: from mga18.intel.com ([134.134.136.126]:54953 "EHLO mga18.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725790AbeKMFC2 (ORCPT ); Tue, 13 Nov 2018 00:02:28 -0500 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga006.jf.intel.com ([10.7.209.51]) by orsmga106.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Nov 2018 11:07:55 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.54,496,1534834800"; d="scan'208";a="90559950" Received: from ray.jf.intel.com (HELO [10.7.201.139]) ([10.7.201.139]) by orsmga006.jf.intel.com with ESMTP; 12 Nov 2018 11:07:55 -0800 Subject: Re: [PATCH] x86/mm/pat: Fix missing preemption disable for __native_flush_tlb() To: Dan Williams , Andy Lutomirski Cc: Thomas Gleixner , Sebastian Andrzej Siewior , Andy Lutomirski , Dave Hansen , Peter Zijlstra , Borislav Petkov , stable , X86 ML , Linux Kernel Mailing List , "Kirill A. Shutemov" References: <154180834787.2060925.7738215365584115230.stgit@dwillia2-desk3.amr.corp.intel.com> <7590EF40-B0CF-40BD-9D29-FB731A2A2E3A@amacapital.net> <9DFD717D-857D-493D-A606-B635D72BAC21@amacapital.net> From: Dave Hansen Openpgp: preference=signencrypt Autocrypt: addr=dave.hansen@intel.com; keydata= xsFNBE6HMP0BEADIMA3XYkQfF3dwHlj58Yjsc4E5y5G67cfbt8dvaUq2fx1lR0K9h1bOI6fC oAiUXvGAOxPDsB/P6UEOISPpLl5IuYsSwAeZGkdQ5g6m1xq7AlDJQZddhr/1DC/nMVa/2BoY 2UnKuZuSBu7lgOE193+7Uks3416N2hTkyKUSNkduyoZ9F5twiBhxPJwPtn/wnch6n5RsoXsb ygOEDxLEsSk/7eyFycjE+btUtAWZtx+HseyaGfqkZK0Z9bT1lsaHecmB203xShwCPT49Blxz VOab8668QpaEOdLGhtvrVYVK7x4skyT3nGWcgDCl5/Vp3TWA4K+IofwvXzX2ON/Mj7aQwf5W iC+3nWC7q0uxKwwsddJ0Nu+dpA/UORQWa1NiAftEoSpk5+nUUi0WE+5DRm0H+TXKBWMGNCFn c6+EKg5zQaa8KqymHcOrSXNPmzJuXvDQ8uj2J8XuzCZfK4uy1+YdIr0yyEMI7mdh4KX50LO1 pmowEqDh7dLShTOif/7UtQYrzYq9cPnjU2ZW4qd5Qz2joSGTG9eCXLz5PRe5SqHxv6ljk8mb ApNuY7bOXO/A7T2j5RwXIlcmssqIjBcxsRRoIbpCwWWGjkYjzYCjgsNFL6rt4OL11OUF37wL QcTl7fbCGv53KfKPdYD5hcbguLKi/aCccJK18ZwNjFhqr4MliQARAQABzShEYXZpZCBDaHJp c3RvcGhlciBIYW5zZW4gPGRhdmVAc3I3MS5uZXQ+wsF7BBMBAgAlAhsDBgsJCAcDAgYVCAIJ CgsEFgIDAQIeAQIXgAUCTo3k0QIZAQAKCRBoNZUwcMmSsMO2D/421Xg8pimb9mPzM5N7khT0 2MCnaGssU1T59YPE25kYdx2HntwdO0JA27Wn9xx5zYijOe6B21ufrvsyv42auCO85+oFJWfE K2R/IpLle09GDx5tcEmMAHX6KSxpHmGuJmUPibHVbfep2aCh9lKaDqQR07gXXWK5/yU1Dx0r VVFRaHTasp9fZ9AmY4K9/BSA3VkQ8v3OrxNty3OdsrmTTzO91YszpdbjjEFZK53zXy6tUD2d e1i0kBBS6NLAAsqEtneplz88T/v7MpLmpY30N9gQU3QyRC50jJ7LU9RazMjUQY1WohVsR56d ORqFxS8ChhyJs7BI34vQusYHDTp6PnZHUppb9WIzjeWlC7Jc8lSBDlEWodmqQQgp5+6AfhTD kDv1a+W5+ncq+Uo63WHRiCPuyt4di4/0zo28RVcjtzlGBZtmz2EIC3vUfmoZbO/Gn6EKbYAn rzz3iU/JWV8DwQ+sZSGu0HmvYMt6t5SmqWQo/hyHtA7uF5Wxtu1lCgolSQw4t49ZuOyOnQi5 f8R3nE7lpVCSF1TT+h8kMvFPv3VG7KunyjHr3sEptYxQs4VRxqeirSuyBv1TyxT+LdTm6j4a mulOWf+YtFRAgIYyyN5YOepDEBv4LUM8Tz98lZiNMlFyRMNrsLV6Pv6SxhrMxbT6TNVS5D+6 UorTLotDZKp5+M7BTQRUY85qARAAsgMW71BIXRgxjYNCYQ3Xs8k3TfAvQRbHccky50h99TUY sqdULbsb3KhmY29raw1bgmyM0a4DGS1YKN7qazCDsdQlxIJp9t2YYdBKXVRzPCCsfWe1dK/q 66UVhRPP8EGZ4CmFYuPTxqGY+dGRInxCeap/xzbKdvmPm01Iw3YFjAE4PQ4hTMr/H76KoDbD cq62U50oKC83ca/PRRh2QqEqACvIH4BR7jueAZSPEDnzwxvVgzyeuhwqHY05QRK/wsKuhq7s UuYtmN92Fasbxbw2tbVLZfoidklikvZAmotg0dwcFTjSRGEg0Gr3p/xBzJWNavFZZ95Rj7Et db0lCt0HDSY5q4GMR+SrFbH+jzUY/ZqfGdZCBqo0cdPPp58krVgtIGR+ja2Mkva6ah94/oQN lnCOw3udS+Eb/aRcM6detZr7XOngvxsWolBrhwTQFT9D2NH6ryAuvKd6yyAFt3/e7r+HHtkU kOy27D7IpjngqP+b4EumELI/NxPgIqT69PQmo9IZaI/oRaKorYnDaZrMXViqDrFdD37XELwQ gmLoSm2VfbOYY7fap/AhPOgOYOSqg3/Nxcapv71yoBzRRxOc4FxmZ65mn+q3rEM27yRztBW9 AnCKIc66T2i92HqXCw6AgoBJRjBkI3QnEkPgohQkZdAb8o9WGVKpfmZKbYBo4pEAEQEAAcLB XwQYAQIACQUCVGPOagIbDAAKCRBoNZUwcMmSsJeCEACCh7P/aaOLKWQxcnw47p4phIVR6pVL e4IEdR7Jf7ZL00s3vKSNT+nRqdl1ugJx9Ymsp8kXKMk9GSfmZpuMQB9c6io1qZc6nW/3TtvK pNGz7KPPtaDzvKA4S5tfrWPnDr7n15AU5vsIZvgMjU42gkbemkjJwP0B1RkifIK60yQqAAlT YZ14P0dIPdIPIlfEPiAWcg5BtLQU4Wg3cNQdpWrCJ1E3m/RIlXy/2Y3YOVVohfSy+4kvvYU3 lXUdPb04UPw4VWwjcVZPg7cgR7Izion61bGHqVqURgSALt2yvHl7cr68NYoFkzbNsGsye9ft M9ozM23JSgMkRylPSXTeh5JIK9pz2+etco3AfLCKtaRVysjvpysukmWMTrx8QnI5Nn5MOlJj 1Ov4/50JY9pXzgIDVSrgy6LYSMc4vKZ3QfCY7ipLRORyalFDF3j5AGCMRENJjHPD6O7bl3Xo 4DzMID+8eucbXxKiNEbs21IqBZbbKdY1GkcEGTE7AnkA3Y6YB7I/j9mQ3hCgm5muJuhM/2Fr OPsw5tV/LmQ5GXH0JQ/TZXWygyRFyyI2FqNTx4WHqUn3yFj8rwTAU1tluRUYyeLy0ayUlKBH ybj0N71vWO936MqP6haFERzuPAIpxj2ezwu0xb1GjTk4ynna6h5GjnKgdfOWoRtoWndMZxbA z5cecg== Message-ID: <749919a4-cdb1-48a3-adb4-adb81a5fa0b5@intel.com> Date: Mon, 12 Nov 2018 11:07:55 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 11/10/18 4:31 PM, Dan Williams wrote: >> If it indeed can run late in boot or after boot, then it sure looks >> buggy. Either the __flush_tlb_all() should be removed or it should >> be replaced with flush_tlb_kernel_range(). It’s unclear to me why a >> flush is needed at all, but if it’s needed, surely all CPUs need >> flushing. > Yeah, I don't think __flush_tlb_all() is needed at > kernel_physical_mapping_init() time, and at > kernel_physical_mapping_remove() time we do a full flush_tlb_all(). It doesn't look strictly necessary to me. I _think_ we're only ever populating previously non-present entries, and those never need TLB flushes. I didn't look too deeply, so I'd appreciate anyone else double-checking me on this. The __flush_tlb_all() actually appears to predate git and it was originally entirely intended for early-boot-only. It probably lasted this long because it looks really important. :) It was even next to where we set MMU features in CR4, which is *really* early in boot: > + asm volatile("movq %%cr4,%0" : "=r" (mmu_cr4_features)); > + __flush_tlb_all(); I also totally agree with Andy that if it were needed on the local CPU, this code would be buggy because it doesn't initiate any *remote* TLB flushes. So, let's remove it, but also add some comments about not being allowed to *change* page table entries, only populate them. We could even add some warnings to keep this enforced.