All of lore.kernel.org
 help / color / mirror / Atom feed
From: Steven Rostedt <rostedt@goodmis.org>
To: linux-kernel@vger.kernel.org
Cc: Ingo Molnar <mingo@kernel.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	stable@vger.kernel.org,
	"Tzvetomir Stoyanov (VMware)" <tz.stoyanov@gmail.com>,
	Joerg Roedel <jroedel@suse.de>
Subject: [for-linus][PATCH 6/9] tracing: Add a vmalloc_sync_mappings() for safe measure
Date: Thu, 07 May 2020 13:39:10 -0400	[thread overview]
Message-ID: <20200507173929.118079761@goodmis.org> (raw)
In-Reply-To: 20200507173904.729935165@goodmis.org

From: "Steven Rostedt (VMware)" <rostedt@goodmis.org>

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>
---
 kernel/trace/trace.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 8d2b98812625..9ed6d92768af 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -8525,6 +8525,19 @@ static int allocate_trace_buffers(struct trace_array *tr, int size)
 	 */
 	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;
 }
 
-- 
2.26.2



  parent reply	other threads:[~2020-05-07 17:39 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-07 17:39 [for-linus][PATCH 0/9] tracing: Fixes for 5.7 Steven Rostedt
2020-05-07 17:39 ` [for-linus][PATCH 1/9] bootconfig: Fix to remove bootconfig data from initrd while boot Steven Rostedt
2020-05-07 17:39 ` [for-linus][PATCH 2/9] tracing/kprobes: Fix a double initialization typo Steven Rostedt
2020-05-07 17:39 ` [for-linus][PATCH 3/9] tracing/boottime: Fix kprobe event API usage Steven Rostedt
2020-05-07 17:39 ` [for-linus][PATCH 4/9] tracing/kprobes: Reject new event if loc is NULL Steven Rostedt
2020-05-07 17:39 ` [for-linus][PATCH 5/9] tracing: Wait for preempt irq delay thread to finish Steven Rostedt
2020-05-07 17:39 ` Steven Rostedt [this message]
2020-05-07 17:39 ` [for-linus][PATCH 7/9] gpu/trace: Minor comment updates for gpu_mem_total tracepoint Steven Rostedt
2020-05-07 17:39 ` [for-linus][PATCH 8/9] tracing: Fix doc mistakes in trace sample Steven Rostedt
2020-05-07 17:39 ` [for-linus][PATCH 9/9] tracing: Make tracing_snapshot_instance_cond() static Steven Rostedt
2020-05-07 18:22 ` [for-linus][PATCH 10/9] tools/bootconfig: Fix resource leak in apply_xbc() Steven Rostedt

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200507173929.118079761@goodmis.org \
    --to=rostedt@goodmis.org \
    --cc=akpm@linux-foundation.org \
    --cc=jroedel@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@kernel.org \
    --cc=stable@vger.kernel.org \
    --cc=tz.stoyanov@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.