Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754322AbdFWFHU (ORCPT ); Fri, 23 Jun 2017 01:07:20 -0400 Received: from mail-oi0-f53.google.com ([209.85.218.53]:35161 "EHLO mail-oi0-f53.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754252AbdFWFHT (ORCPT ); Fri, 23 Jun 2017 01:07:19 -0400 MIME-Version: 1.0 In-Reply-To: <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> <3908561D78D1C84285E8C5FCA982C28F612DCCAF@ORSMSX114.amr.corp.intel.com> From: Dan Williams Date: Thu, 22 Jun 2017 22:07:18 -0700 Message-ID: Subject: Re: [PATCH] mm/hwpoison: Clear PRESENT bit for kernel 1:1 mappings of poison pages To: "Luck, Tony" Cc: "Elliott, Robert (Persistent Memory)" , Naoya Horiguchi , Borislav Petkov , "Hansen, Dave" , "x86@kernel.org" , "linux-mm@kvack.org" , "linux-kernel@vger.kernel.org" , "linux-nvdimm@lists.01.org" , "Kani, Toshimitsu" , "Vaden, Tom (HPE Server OS Architecture)" Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1406 Lines: 29 On Wed, Jun 21, 2017 at 1:30 PM, Luck, Tony wrote: >> 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? We don't unpoison pmem without new data to write in it's place. What context is arch_handle_poison() called? Ideally we only "clear" poison when we know we are trying to write zero over the poisoned range.