| Message ID | 20190719184652.11391-4-joro@8bytes.org (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | Sync unmappings in vmalloc/ioremap areas | expand |
Srewed up the subject :(, it needs to be "mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()" of course. On Fri, Jul 19, 2019 at 08:46:52PM +0200, Joerg Roedel wrote: > From: Joerg Roedel <jroedel@suse.de> > > 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 region 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 before > the regions can be re-used. > > References: https://bugzilla.suse.com/show_bug.cgi?id=1118689 > Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com> > Fixes: 5d72b4fba40ef ('x86, mm: support huge I/O mapping capability I/F') > Signed-off-by: Joerg Roedel <jroedel@suse.de> > --- > mm/vmalloc.c | 9 +++++++++ > 1 file changed, 9 insertions(+) > > diff --git a/mm/vmalloc.c b/mm/vmalloc.c > index 4fa8d84599b0..e0fc963acc41 100644 > --- a/mm/vmalloc.c > +++ b/mm/vmalloc.c > @@ -1258,6 +1258,12 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) > if (unlikely(valist == NULL)) > return false; > > + /* > + * First make sure the mappings are removed from all page-tables > + * before they are freed. > + */ > + vmalloc_sync_all(); > + > /* > * TODO: to calculate a flush range without looping. > * The list can be up to lazy_max_pages() elements. > @@ -3038,6 +3044,9 @@ EXPORT_SYMBOL(remap_vmalloc_range); > /* > * Implement a stub for vmalloc_sync_all() if the architecture chose not to > * have one. > + * > + * The purpose of this function is to make sure the vmalloc area > + * mappings are identical in all page-tables in the system. > */ > void __weak vmalloc_sync_all(void) > { > -- > 2.17.1
On Mon, 22 Jul 2019, Joerg Roedel wrote:
> Srewed up the subject :(, it needs to be
Un-Srewed it :)
^^^^^^
On Mon, Jul 22, 2019 at 10:19:32AM +0200, Thomas Gleixner wrote: > On Mon, 22 Jul 2019, Joerg Roedel wrote: > > > Srewed up the subject :(, it needs to be > > Un-Srewed it :) Thanks a lot :)
diff --git a/mm/vmalloc.c b/mm/vmalloc.c index 4fa8d84599b0..e0fc963acc41 100644 --- a/mm/vmalloc.c +++ b/mm/vmalloc.c @@ -1258,6 +1258,12 @@ static bool __purge_vmap_area_lazy(unsigned long start, unsigned long end) if (unlikely(valist == NULL)) return false; + /* + * First make sure the mappings are removed from all page-tables + * before they are freed. + */ + vmalloc_sync_all(); + /* * TODO: to calculate a flush range without looping. * The list can be up to lazy_max_pages() elements. @@ -3038,6 +3044,9 @@ EXPORT_SYMBOL(remap_vmalloc_range); /* * Implement a stub for vmalloc_sync_all() if the architecture chose not to * have one. + * + * The purpose of this function is to make sure the vmalloc area + * mappings are identical in all page-tables in the system. */ void __weak vmalloc_sync_all(void) {