From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751865AbdFUUTh convert rfc822-to-8bit (ORCPT ); Wed, 21 Jun 2017 16:19:37 -0400 Received: from mga14.intel.com ([192.55.52.115]:51525 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751106AbdFUUTg (ORCPT ); Wed, 21 Jun 2017 16:19:36 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,370,1493708400"; d="scan'208";a="870407473" 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 , "Williams, Dan J" , "Kani, Toshimitsu" , "Vaden, Tom (HPE Server OS Architecture)" 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: AQHS5tyGLdf2jBRppESVUPAeACzObaIs89uAgAKrYACAAJoSgP//jwKw Date: Wed, 21 Jun 2017 20:19:34 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F612DCC2E@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.139] 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 >> +if (set_memory_np(decoy_addr, 1)) >> +pr_warn("Could not invalidate pfn=0x%lx from 1:1 map \n", pfn); > > Does this patch handle breaking up 512 GiB, 1 GiB or 2 MiB page mappings > if it's just trying to mark a 4 KiB page as bad? Yes. The 1:1 mappings start out using the largest supported page size. This call will break up huge/large pages so that only 4KB is mapped out. [This will affect performance because of the extra levels of TLB walks] > Although the kernel doesn't use MTRRs itself anymore, what if the system > BIOS still uses them for some memory regions, and the bad address falls in > an MTRR region? This code is called after mm/memory-failure.c:memory_failure() has already checked that the page is one managed by the kernel. In general machine checks from other regions are going to be called out as fatal before we get here. -Tony