From: Greg Kroah-Hartman Date: Tue, 12 May 2020 11:11:52 +0000 (+0200) Subject: drop queue-4.4/tracing-add-a-vmalloc_sync_mappings-for-safe-measure.patch X-Git-Tag: v4.19.123~36 X-Git-Url: http://git.ipfire.org/gitweb.cgi?a=commitdiff_plain;h=1a485b686d4c0f6a62dd74f6932abdd3d5072e12;p=thirdparty%2Fkernel%2Fstable-queue.git 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 a5aae02ead2..0ea26bebea8 100644 --- 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 index 6856bcf4f48..00000000000 --- 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)" -Date: Wed, 6 May 2020 10:36:18 -0400 -Subject: tracing: Add a vmalloc_sync_mappings() for safe measure - -From: Steven Rostedt (VMware) - -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)" -Suggested-by: Joerg Roedel -Signed-off-by: Steven Rostedt (VMware) -Signed-off-by: Greg Kroah-Hartman - ---- - 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; - } -