Remove redundant patch (vmalloc)5.2-10

1800_vmalloc-sync-unmappings-fix.patch
mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()

2 files changed, 0 insertions, 62 deletions

diff --git a/0000_README b/0000_README
index 4179af77..eb585a91 100644
--- a/0000_README
+++ b/0000_README
@@ -87,10 +87,6 @@ Patch:  1510_fs-enable-link-security-restrictions-by-default.patch
 From:   http://sources.debian.net/src/linux/3.16.7-ckt4-3/debian/patches/debian/fs-enable-link-security-restrictions-by-default.patch/
 Desc:   Enable link security restrictions by default.
 
-Patch: 	1800_vmalloc-sync-unmappings-fix.patch
-From:		https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/patch/?id=3f8fd02b1bf1d7ba964485a56f2f4b53ae88c167
-Desc:		mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()
-
 Patch:  2000_BT-Check-key-sizes-only-if-Secure-Simple-Pairing-enabled.patch
 From:   https://lore.kernel.org/linux-bluetooth/20190522070540.48895-1-marcel@holtmann.org/raw
 Desc:   Bluetooth: Check key sizes only when Secure Simple Pairing is enabled. See bug #686758
diff --git a/1800_vmalloc-sync-unmappings-fix.patch b/1800_vmalloc-sync-unmappings-fix.patch
deleted file mode 100644
index 7e56e512..00000000
--- a/1800_vmalloc-sync-unmappings-fix.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From 3f8fd02b1bf1d7ba964485a56f2f4b53ae88c167 Mon Sep 17 00:00:00 2001
-From: Joerg Roedel <jroedel@suse.de>
-Date: Fri, 19 Jul 2019 20:46:52 +0200
-Subject: mm/vmalloc: Sync unmappings in __purge_vmap_area_lazy()
-
-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
-Fixes: 5d72b4fba40ef ('x86, mm: support huge I/O mapping capability I/F')
-Signed-off-by: Joerg Roedel <jroedel@suse.de>
-Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
-Reviewed-by: Dave Hansen <dave.hansen@linux.intel.com>
-Link: https://lkml.kernel.org/r/20190719184652.11391-4-joro@8bytes.org
----
- 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)
- {
--- 
-cgit 1.2-0.3.lf.el7
-