On Wed, Jul 17, 2019 at 12:14 AM Joerg Roedel <joro@xxxxxxxxxx> wrote: > > From: Joerg Roedel <jroedel@xxxxxxx> > > On x86-32 with PTI enabled, parts of the kernel page-tables > are not shared between processes. This can cause mappings in > the vmalloc/ioremap area to persist in some page-tables > after the regions is unmapped and released. > > When the region is re-used the processes with the old > mappings do not fault in the new mappings but still access > the old ones. > > This causes undefined behavior, in reality often data > corruption, kernel oopses and panics and even spontaneous > reboots. > > Fix this problem by activly syncing unmaps in the > vmalloc/ioremap area to all page-tables in the system. > > References: https://bugzilla.suse.com/show_bug.cgi?id=1118689 > Fixes: 5d72b4fba40ef ('x86, mm: support huge I/O mapping capability I/F') > Signed-off-by: Joerg Roedel <jroedel@xxxxxxx> > --- > mm/vmalloc.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 4fa8d84599b0..322b11a374fd 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -132,6 +132,8 @@ static void vunmap_page_range(unsigned long addr, unsigned long end) > continue; > vunmap_p4d_range(pgd, addr, next); > } while (pgd++, addr = next, addr != end); > + > + vmalloc_sync_all(); > } I'm confused. Shouldn't the code in _vm_unmap_aliases handle this? As it stands, won't your patch hurt performance on x86_64? If x86_32 is a special snowflake here, maybe flush_tlb_kernel_range() should handle this? Even if your patch is correct, a comment would be nice
