| Message ID | 20190715110212.18617-2-joro@8bytes.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Sync unmappings in vmalloc/ioremap areas | expand |
On Mon, 15 Jul 2019, Joerg Roedel wrote: > From: Joerg Roedel <jroedel@suse.de> > > Do not require a struct page for the mapped memory location > because it might not exist. This can happen when an > ioremapped region is mapped with 2MB pages. > > Signed-off-by: Joerg Roedel <jroedel@suse.de> Lacks a Fixes tag, hmm?
On Mon, Jul 15, 2019 at 03:08:42PM +0200, Thomas Gleixner wrote: > On Mon, 15 Jul 2019, Joerg Roedel wrote: > > > From: Joerg Roedel <jroedel@suse.de> > > > > Do not require a struct page for the mapped memory location > > because it might not exist. This can happen when an > > ioremapped region is mapped with 2MB pages. > > > > Signed-off-by: Joerg Roedel <jroedel@suse.de> > > Lacks a Fixes tag, hmm? Yeah, right, the question is, which commit to put in there. The problem results from two changes: 1) Introduction of !SHARED_KERNEL_PMD path in x86-32. In itself this is not a problem, and the path was only enabled for Xen-PV. 2) Huge IORemapings which use the PMD level. Also not a problem by itself, but together with !SHARED_KERNEL_PMD problematic because it requires to sync the PMD entries between all page-tables, and that was not implemented. Before PTI-x32 was merged this problem did not show up, maybe because the 32-bit Xen-PV users did not trigger it. But with PTI-x32 all PAE users run with !SHARED_KERNEL_PMD and the problem popped up. For the last patch I put the PTI-x32 enablement commit in the fixes tag, because that was the one that showed up during bisection. But more correct would probably be 5d72b4fba40e ('x86, mm: support huge I/O mapping capability I/F') Or do I miss something? Regards, Joerg
On Mon, 15 Jul 2019, Joerg Roedel wrote: > On Mon, Jul 15, 2019 at 03:08:42PM +0200, Thomas Gleixner wrote: > > On Mon, 15 Jul 2019, Joerg Roedel wrote: > > > > > From: Joerg Roedel <jroedel@suse.de> > > > > > > Do not require a struct page for the mapped memory location > > > because it might not exist. This can happen when an > > > ioremapped region is mapped with 2MB pages. > > > > > > Signed-off-by: Joerg Roedel <jroedel@suse.de> > > > > Lacks a Fixes tag, hmm? > > Yeah, right, the question is, which commit to put in there. The problem > results from two changes: > > 1) Introduction of !SHARED_KERNEL_PMD path in x86-32. In itself > this is not a problem, and the path was only enabled for > Xen-PV. > > 2) Huge IORemapings which use the PMD level. Also not a problem > by itself, but together with !SHARED_KERNEL_PMD problematic > because it requires to sync the PMD entries between all > page-tables, and that was not implemented. > > Before PTI-x32 was merged this problem did not show up, maybe because > the 32-bit Xen-PV users did not trigger it. But with PTI-x32 all PAE > users run with !SHARED_KERNEL_PMD and the problem popped up. > > For the last patch I put the PTI-x32 enablement commit in the fixes tag, > because that was the one that showed up during bisection. But more > correct would probably be > > 5d72b4fba40e ('x86, mm: support huge I/O mapping capability I/F') Looks about right. Thanks, tglx
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 794f364cb882..4a4049f6d458 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -200,7 +200,7 @@ static inline pmd_t *vmalloc_sync_one(pgd_t *pgd, unsigned long address) if (!pmd_present(*pmd)) set_pmd(pmd, *pmd_k); else - BUG_ON(pmd_page(*pmd) != pmd_page(*pmd_k)); + BUG_ON(pmd_pfn(*pmd) != pmd_pfn(*pmd_k)); return pmd_k; }