[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM2PR21MB00892878E2A17E076A18C795CBF90@DM2PR21MB0089.namprd21.prod.outlook.com>
Date: Tue, 6 Sep 2016 17:20:47 +0000
From: Matthew Wilcox <mawilcox@...rosoft.com>
To: Dan Williams <dan.j.williams@...el.com>,
"linux-nvdimm@...ts.01.org" <linux-nvdimm@...ts.01.org>
CC: Toshi Kani <toshi.kani@....com>,
Nilesh Choudhury <nilesh.choudhury@...cle.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"stable@...r.kernel.org" <stable@...r.kernel.org>,
"linux-mm@...ck.org" <linux-mm@...ck.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
Ross Zwisler <ross.zwisler@...ux.intel.com>,
"Kirill A. Shutemov" <kirill.shutemov@...ux.intel.com>,
Kai Zhang <kai.ka.zhang@...cle.com>
Subject: RE: [PATCH 4/5] mm: fix cache mode of dax pmd mappings
I have no objection to this patch going in for now.
Longer term, surely we want to track what mode the PFNs are mapped in? There are various bizarre suppositions out there about how persistent memory should be mapped, and it's probably better if the kernel ignores what the user specifies and keeps everything sane. I've read the dire warnings in the Intel architecture manual and I have no desire to deal with the inevitable bug reports on some hardware I don't own and requires twenty weeks of operation in order to observe the bug.
-----Original Message-----
From: Dan Williams [mailto:dan.j.williams@...el.com]
Sent: Tuesday, September 6, 2016 12:50 PM
To: linux-nvdimm@...ts.01.org
Cc: Toshi Kani <toshi.kani@....com>; Matthew Wilcox <mawilcox@...rosoft.com>; Nilesh Choudhury <nilesh.choudhury@...cle.com>; linux-kernel@...r.kernel.org; stable@...r.kernel.org; linux-mm@...ck.org; akpm@...ux-foundation.org; Ross Zwisler <ross.zwisler@...ux.intel.com>; Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>; Kai Zhang <kai.ka.zhang@...cle.com>
Subject: [PATCH 4/5] mm: fix cache mode of dax pmd mappings
track_pfn_insert() is marking dax mappings as uncacheable.
It is used to keep mappings attributes consistent across a remapped range.
However, since dax regions are never registered via track_pfn_remap(), the caching mode lookup for dax pfns always returns _PAGE_CACHE_MODE_UC. We do not use track_pfn_insert() in the dax-pte path, and we always want to use the pgprot of the vma itself, so drop this call.
Cc: Ross Zwisler <ross.zwisler@...ux.intel.com>
Cc: Matthew Wilcox <mawilcox@...rosoft.com>
Cc: Kirill A. Shutemov <kirill.shutemov@...ux.intel.com>
Cc: Andrew Morton <akpm@...ux-foundation.org>
Cc: Nilesh Choudhury <nilesh.choudhury@...cle.com>
Reported-by: Kai Zhang <kai.ka.zhang@...cle.com>
Reported-by: Toshi Kani <toshi.kani@....com>
Cc: <stable@...r.kernel.org>
Signed-off-by: Dan Williams <dan.j.williams@...el.com>
---
mm/huge_memory.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c index a6abd76baa72..338eff05c77a 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -676,8 +676,6 @@ int vmf_insert_pfn_pmd(struct vm_area_struct *vma, unsigned long addr,
if (addr < vma->vm_start || addr >= vma->vm_end)
return VM_FAULT_SIGBUS;
- if (track_pfn_insert(vma, &pgprot, pfn))
- return VM_FAULT_SIGBUS;
insert_pfn_pmd(vma, addr, pmd, pfn, pgprot, write);
return VM_FAULT_NOPAGE;
}
Powered by blists - more mailing lists