On Wed, Jun 21, 2017 at 1:30 PM, Luck, Tony <tony.l...@intel.com> 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.
