drop queue-4.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch

diff --git a/queue-4.4/series b/queue-4.4/series
index a5aae02ead20b685840bc435c65d7cbf5ae5d433..0ea26bebea8ee1c0d1f6eb49026a916a8d279cc0 100644 (file)
--- a/queue-4.4/series
+++ b/queue-4.4/series
@@ -12,4 +12,3 @@ x86-apm-don-t-access-__preempt_count-with-zeroed-fs.patch
 revert-ib-ipoib-update-broadcast-object-if-pkey-value-was-changed-in-index-0.patch
 usb-uas-add-quirk-for-lacie-2big-quadra.patch
 usb-serial-garmin_gps-add-sanity-checking-for-data-length.patch
-tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch

diff --git a/queue-4.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch b/queue-4.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch
deleted file mode 100644 (file)
index 6856bcf..0000000
--- a/queue-4.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch
+++ /dev/null
@@ -1,62 +0,0 @@
-From 11f5efc3ab66284f7aaacc926e9351d658e2577b Mon Sep 17 00:00:00 2001
-From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>
-Date: Wed, 6 May 2020 10:36:18 -0400
-Subject: tracing: Add a vmalloc_sync_mappings() for safe measure
-
-From: Steven Rostedt (VMware) <rostedt@goodmis.org>
-
-commit 11f5efc3ab66284f7aaacc926e9351d658e2577b upstream.
-
-x86_64 lazily maps in the vmalloc pages, and the way this works with per_cpu
-areas can be complex, to say the least. Mappings may happen at boot up, and
-if nothing synchronizes the page tables, those page mappings may not be
-synced till they are used. This causes issues for anything that might touch
-one of those mappings in the path of the page fault handler. When one of
-those unmapped mappings is touched in the page fault handler, it will cause
-another page fault, which in turn will cause a page fault, and leave us in
-a loop of page faults.
-
-Commit 763802b53a42 ("x86/mm: split vmalloc_sync_all()") split
-vmalloc_sync_all() into vmalloc_sync_unmappings() and
-vmalloc_sync_mappings(), as on system exit, it did not need to do a full
-sync on x86_64 (although it still needed to be done on x86_32). By chance,
-the vmalloc_sync_all() would synchronize the page mappings done at boot up
-and prevent the per cpu area from being a problem for tracing in the page
-fault handler. But when that synchronization in the exit of a task became a
-nop, it caused the problem to appear.
-
-Link: https://lore.kernel.org/r/20200429054857.66e8e333@oasis.local.home
-
-Cc: stable@vger.kernel.org
-Fixes: 737223fbca3b1 ("tracing: Consolidate buffer allocation code")
-Reported-by: "Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>
-Suggested-by: Joerg Roedel <jroedel@suse.de>
-Signed-off-by: Steven Rostedt (VMware) <rostedt@goodmis.org>
-Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
----
- kernel/trace/trace.c |   13 +++++++++++++
- 1 file changed, 13 insertions(+)
-
---- a/kernel/trace/trace.c
-+++ b/kernel/trace/trace.c
-@@ -6621,6 +6621,19 @@ static int allocate_trace_buffers(struct
-        */
-       allocate_snapshot = false;
- #endif
-+
-+      /*
-+       * Because of some magic with the way alloc_percpu() works on
-+       * x86_64, we need to synchronize the pgd of all the tables,
-+       * otherwise the trace events that happen in x86_64 page fault
-+       * handlers can't cope with accessing the chance that a
-+       * alloc_percpu()'d memory might be touched in the page fault trace
-+       * event. Oh, and we need to audit all other alloc_percpu() and vmalloc()
-+       * calls in tracing, because something might get triggered within a
-+       * page fault trace event!
-+       */
-+      vmalloc_sync_mappings();
-+
-       return 0;
- }
-