Ingo, Is it possible to ack the x86 bits in this patch series? I'm hoping to get this pulled through the libnvdimm tree for 4.19. Thanks! On 07/13/2018 09:49 PM, Dan Williams wrote: > Changes since v5 [1]: > * Move put_page() before memory_failure() in madvise_inject_error() > (Naoya) > * The previous change uncovered a latent bug / broken assumption in > __put_devmap_managed_page(). We need to preserve page->mapping for > dax pages when they go idle. > * Rename mapping_size() to dev_pagemap_mapping_size() (Naoya) > * Catch and fail attempts to soft-offline dax pages (Naoya) > * Collect Naoya's ack on "mm, memory_failure: Collect mapping size in > collect_procs()" > > [1]: https://lists.01.org/pipermail/linux-nvdimm/2018-July/016682.html > > --- > > As it stands, memory_failure() gets thoroughly confused by dev_pagemap > backed mappings. The recovery code has specific enabling for several > possible page states and needs new enabling to handle poison in dax > mappings. > > In order to support reliable reverse mapping of user space addresses: > > 1/ Add new locking in the memory_failure() rmap path to prevent races > that would typically be handled by the page lock. > > 2/ Since dev_pagemap pages are hidden from the page allocator and the > "compound page" accounting machinery, add a mechanism to determine the > size of the mapping that encompasses a given poisoned pfn. > > 3/ Given pmem errors can be repaired, change the speculatively accessed > poison protection, mce_unmap_kpfn(), to be reversible and otherwise > allow ongoing access from the kernel. > > A side effect of this enabling is that MADV_HWPOISON becomes usable for > dax mappings, however the primary motivation is to allow the system to > survive userspace consumption of hardware-poison via dax. Specifically > the current behavior is: > > mce: Uncorrected hardware memory error in user-access at af34214200 > {1}[Hardware Error]: It has been corrected by h/w and requires no further action > mce: [Hardware Error]: Machine check events logged > {1}[Hardware Error]: event severity: corrected > Memory failure: 0xaf34214: reserved kernel page still referenced by 1 users > [..] > Memory failure: 0xaf34214: recovery action for reserved kernel page: Failed > mce: Memory error not recovered > <reboot> > > ...and with these changes: > > Injecting memory failure for pfn 0x20cb00 at process virtual address 0x7f763dd00000 > Memory failure: 0x20cb00: Killing dax-pmd:5421 due to hardware memory corruption > Memory failure: 0x20cb00: recovery action for dax page: Recovered > > Given all the cross dependencies I propose taking this through > nvdimm.git with acks from Naoya, x86/core, x86/RAS, and of course dax > folks. > > --- > > Dan Williams (13): > device-dax: Convert to vmf_insert_mixed and vm_fault_t > device-dax: Enable page_mapping() > device-dax: Set page->index > filesystem-dax: Set page->index > mm, madvise_inject_error: Disable MADV_SOFT_OFFLINE for ZONE_DEVICE pages > mm, dev_pagemap: Do not clear ->mapping on final put > mm, madvise_inject_error: Let memory_failure() optionally take a page reference > mm, memory_failure: Collect mapping size in collect_procs() > filesystem-dax: Introduce dax_lock_mapping_entry() > mm, memory_failure: Teach memory_failure() about dev_pagemap pages > x86/mm/pat: Prepare {reserve,free}_memtype() for "decoy" addresses > x86/memory_failure: Introduce {set,clear}_mce_nospec() > libnvdimm, pmem: Restore page attributes when clearing errors > > > arch/x86/include/asm/set_memory.h | 42 ++++++ > arch/x86/kernel/cpu/mcheck/mce-internal.h | 15 -- > arch/x86/kernel/cpu/mcheck/mce.c | 38 ----- > arch/x86/mm/pat.c | 16 ++ > drivers/dax/device.c | 75 +++++++--- > drivers/nvdimm/pmem.c | 26 ++++ > drivers/nvdimm/pmem.h | 13 ++ > fs/dax.c | 125 ++++++++++++++++- > include/linux/dax.h | 13 ++ > include/linux/huge_mm.h | 5 - > include/linux/mm.h | 1 > include/linux/set_memory.h | 14 ++ > kernel/memremap.c | 1 > mm/hmm.c | 2 > mm/huge_memory.c | 4 - > mm/madvise.c | 16 ++ > mm/memory-failure.c | 210 +++++++++++++++++++++++------ > 17 files changed, 481 insertions(+), 135 deletions(-) > _______________________________________________ > Linux-nvdimm mailing list > Linux-nvdimm@xxxxxxxxxxxx > https://lists.01.org/mailman/listinfo/linux-nvdimm >
