On Thu, Dec 22, 2016 at 02:18:52PM -0700, Ross Zwisler wrote: > Currently dax_mapping_entry_mkclean() fails to clean and write protect the > pmd_t of a DAX PMD entry during an *sync operation. This can result in > data loss, as detailed in patch 4. > > You can find a working tree here: > > https://git.kernel.org/cgit/linux/kernel/git/zwisler/linux.git/log/?h=dax_pmd_clean_v2 > > This series applies cleanly to mmotm-2016-12-19-16-31. > > Changes since v1: > - Included Dan's patch to kill DAX support for UML. > - Instead of wrapping the DAX PMD code in dax_mapping_entry_mkclean() in > an #ifdef, we now create a stub for pmdp_huge_clear_flush() for the case > when CONFIG_TRANSPARENT_HUGEPAGE isn't defined. (Dan & Jan) > > Dan Williams (1): > dax: kill uml support > > Ross Zwisler (3): > dax: add stub for pmdp_huge_clear_flush() > mm: add follow_pte_pmd() > dax: wrprotect pmd_t in dax_mapping_entry_mkclean > > fs/Kconfig | 2 +- > fs/dax.c | 49 > ++++++++++++++++++++++++++++++------------- > include/asm-generic/pgtable.h | 10 +++++++++ > include/linux/mm.h | 4 ++-- > mm/memory.c | 41 ++++++++++++++++++++++++++++-------- > 5 files changed, 79 insertions(+), 27 deletions(-)
Well, 0-day found another architecture that doesn't define pmd_pfn() et al., so we'll need some more fixes. (Thank you, 0-day, for the coverage!) I have to apologize, I didn't understand that Dan intended his "dax: kill uml support" patch to land in v4.11. I thought he intended it as a cleanup to my series, which really needs to land in v4.10. That's why I folded them together into this v2, along with the wrapper suggested by Jan. Andrew, does it work for you to just keep v1 of this series, and eventually send that to Linus for v4.10? https://lkml.org/lkml/2016/12/20/649 You've already pulled that one into -mm, and it does correctly solve the data loss issue. That would let us deal with getting rid of the #ifdef, blacklisting architectures and introducing the pmdp_huge_clear_flush() strub in a follow-on series for v4.11. _______________________________________________ Linux-nvdimm mailing list Linux-nvdimm@lists.01.org https://lists.01.org/mailman/listinfo/linux-nvdimm