From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga06.intel.com (mga06.intel.com [134.134.136.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id A5F5021BBC409 for ; Wed, 21 Jun 2017 13:29:23 -0700 (PDT) From: "Luck, Tony" Subject: RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages Date: Wed, 21 Jun 2017 20:30:46 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F612DCCAF@ORSMSX114.amr.corp.intel.com> References: <20170616190200.6210-1-tony.luck@intel.com> <20170621021226.GA18024@hori1.linux.bs1.fc.nec.co.jp> <20170621175403.n5kssz32e2oizl7k@intel.com> In-Reply-To: Content-Language: en-US MIME-Version: 1.0 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: linux-nvdimm-bounces@lists.01.org Sender: "Linux-nvdimm" To: "Elliott, Robert (Persistent Memory)" , Naoya Horiguchi Cc: "Vaden, Tom (HPE Server OS Architecture)" , "linux-nvdimm@lists.01.org" , "x86@kernel.org" , "linux-kernel@vger.kernel.org" , "linux-mm@kvack.org" , Hansen, List-ID: > Persistent memory does have unpoisoning and would require this inverse > operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c > nvdimm_clear_poison(). Nice. Well this code will need to cooperate with that ... in particular if the page is in an area that can be unpoisoned ... then we should do that *instead* of marking the page not present (which breaks up huge/large pages and so affects performance). Instead of calling it "arch_unmap_pfn" it could be called something like arch_handle_poison() and do something like: void arch_handle_poison(unsigned long pfn) { if this is a pmem page && pmem_clear_poison(pfn) return if this is a nvdimm page && nvdimm_clear_poison(pfn) return /* can't clear, map out from 1:1 region */ ... code from my patch ... } I'm just not sure how those first two "if" bits work ... particularly in terms of CONFIG dependencies and system capabilities. Perhaps each of pmem and nvdimm could register their unpoison functions and this code could just call each in turn? -Tony _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752116AbdFUUat convert rfc822-to-8bit (ORCPT ); Wed, 21 Jun 2017 16:30:49 -0400 Received: from mga05.intel.com ([192.55.52.43]:18843 "EHLO mga05.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751041AbdFUUas (ORCPT ); Wed, 21 Jun 2017 16:30:48 -0400 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.39,370,1493708400"; d="scan'208";a="100234507" From: "Luck, Tony" To: "Elliott, Robert (Persistent Memory)" , Naoya Horiguchi CC: Borislav Petkov , "Hansen, Dave" , "x86@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "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: AQHS5tyGLdf2jBRppESVUPAeACzObaIvD0eAgACRvICAAJUsgP//k6HA Date: Wed, 21 Jun 2017 20:30:46 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F612DCCAF@ORSMSX114.amr.corp.intel.com> References: <20170616190200.6210-1-tony.luck@intel.com> <20170621021226.GA18024@hori1.linux.bs1.fc.nec.co.jp> <20170621175403.n5kssz32e2oizl7k@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 > Persistent memory does have unpoisoning and would require this inverse > operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c > nvdimm_clear_poison(). Nice. Well this code will need to cooperate with that ... in particular if the page is in an area that can be unpoisoned ... then we should do that *instead* of marking the page not present (which breaks up huge/large pages and so affects performance). Instead of calling it "arch_unmap_pfn" it could be called something like arch_handle_poison() and do something like: void arch_handle_poison(unsigned long pfn) { if this is a pmem page && pmem_clear_poison(pfn) return if this is a nvdimm page && nvdimm_clear_poison(pfn) return /* can't clear, map out from 1:1 region */ ... code from my patch ... } I'm just not sure how those first two "if" bits work ... particularly in terms of CONFIG dependencies and system capabilities. Perhaps each of pmem and nvdimm could register their unpoison functions and this code could just call each in turn? -Tony From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf0-f200.google.com (mail-pf0-f200.google.com [209.85.192.200]) by kanga.kvack.org (Postfix) with ESMTP id C3F2B6B02B4 for ; Wed, 21 Jun 2017 16:30:48 -0400 (EDT) Received: by mail-pf0-f200.google.com with SMTP id r70so168932138pfb.7 for ; Wed, 21 Jun 2017 13:30:48 -0700 (PDT) Received: from mga06.intel.com (mga06.intel.com. [134.134.136.31]) by mx.google.com with ESMTPS id s8si14361301pgr.167.2017.06.21.13.30.47 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 21 Jun 2017 13:30:48 -0700 (PDT) From: "Luck, Tony" Subject: RE: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages Date: Wed, 21 Jun 2017 20:30:46 +0000 Message-ID: <3908561D78D1C84285E8C5FCA982C28F612DCCAF@ORSMSX114.amr.corp.intel.com> References: <20170616190200.6210-1-tony.luck@intel.com> <20170621021226.GA18024@hori1.linux.bs1.fc.nec.co.jp> <20170621175403.n5kssz32e2oizl7k@intel.com> In-Reply-To: Content-Language: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Sender: owner-linux-mm@kvack.org List-ID: To: "Elliott, Robert (Persistent Memory)" , Naoya Horiguchi Cc: Borislav Petkov , "Hansen, Dave" , "x86@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "Williams, Dan J" , "Kani, Toshimitsu" , "Vaden, Tom (HPE Server OS Architecture)" > Persistent memory does have unpoisoning and would require this inverse > operation - see drivers/nvdimm/pmem.c pmem_clear_poison() and core.c > nvdimm_clear_poison(). Nice. Well this code will need to cooperate with that ... in particular if= the page is in an area that can be unpoisoned ... then we should do that *instead* o= f marking the page not present (which breaks up huge/large pages and so affects perfo= rmance). Instead of calling it "arch_unmap_pfn" it could be called something like ar= ch_handle_poison() and do something like: void arch_handle_poison(unsigned long pfn) { if this is a pmem page && pmem_clear_poison(pfn) return if this is a nvdimm page && nvdimm_clear_poison(pfn) return /* can't clear, map out from 1:1 region */ ... code from my patch ... } I'm just not sure how those first two "if" bits work ... particularly in te= rms of CONFIG dependencies and system capabilities. Perhaps each of pmem and nvdimm could register their unpoiso= n functions and this code could just call each in turn? -Tony -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@kvack.org. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: email@kvack.org