Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752923AbdF0WFH convert rfc822-to-8bit (ORCPT ); Tue, 27 Jun 2017 18:05:07 -0400 Received: from mga09.intel.com ([134.134.136.24]:37579 "EHLO mga09.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751684AbdF0WFB (ORCPT ); Tue, 27 Jun 2017 18:05:01 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,272,1496127600"; d="scan'208";a="102069054" From: "Luck, Tony" To: "Elliott, Robert (Persistent Memory)" , Borislav Petkov CC: "Hansen, Dave" , Naoya Horiguchi , "x86@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , Yazen Ghannam , "Kani, Toshimitsu" , "Williams, Dan J" , "linux-nvdimm@lists.01.org" Subject: RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages Thread-Topic: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages Thread-Index: AQHS5tyGLdf2jBRppESVUPAeACzObaIs89uAgAKrYACAA+X7gIAFzTHQ Date: Tue, 27 Jun 2017 22:04:58 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F612E4285@ORSMSX114.amr.corp.intel.com> References: <20170616190200.6210-1-tony.luck@intel.com> <20170619180147.qolal6mz2wlrjbxk@pd.tnic> <20170621174740.npbtg2e4o65tyrss@intel.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [10.22.254.138] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1664 Lines: 36 > > > > +if (set_memory_np(decoy_addr, 1)) > > > > +pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", > > Another concept to consider is mapping the page as UC rather than > completely unmapping it. UC would also avoid the speculative prefetch issue. The Vol 3, Section 11.3 SDM says: Strong Uncacheable (UC) -System memory locations are not cached. All reads and writes appear on the system bus and are executed in program order without reordering. No speculative memory accesses, pagetable walks, or prefetches of speculated branch targets are made. This type of cache-control is useful for memory-mapped I/O devices. When used with normal RAM, it greatly reduces processor performance. But then I went and read the code for set_memory_uc() ... which calls "reserve_memtyep()" which does all kinds of things to avoid issues with MTRRs and other stuff. Which all looks really more complex that we need just here. > The uncorrectable error scope could be smaller than a page size, like: > * memory ECC width (e.g., 8 bytes) > * cache line size (e.g., 64 bytes) > * block device logical block size (e.g., 512 bytes, for persistent memory) > > UC preserves the ability to access adjacent data within the page that > hasn't gone bad, and is particularly useful for persistent memory. If you want to dig into the non-poisoned pieces of the page later it might be better to set up a new scratch UC mapping to do that. My takeaway from Dan's comments on unpoisoning is that this isn't the context that he wants to do that. He'd rather wait until he has somebody overwriting the page with fresh data. So I think I'd like to keep the patch as-is. -Tony