From: Joerg Roedel <jroedel@suse.de>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Peter Zijlstra <peterz@infradead.org>,
Borislav Petkov <bp@alien8.de>,
Andrew Morton <akpm@linux-foundation.org>,
Shile Zhang <shile.zhang@linux.alibaba.com>,
Andy Lutomirski <luto@amacapital.net>,
"Rafael J. Wysocki" <rafael.j.wysocki@intel.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
Tzvetomir Stoyanov <tz.stoyanov@gmail.com>
Subject: [PATCH] percpu: Sync vmalloc mappings in pcpu_alloc() and free_percpu()
Date: Mon, 4 May 2020 17:12:36 +0200 [thread overview]
Message-ID: <20200504151236.GI8135@suse.de> (raw)
In-Reply-To: <20200430223919.50861011@gandalf.local.home>
On Thu, Apr 30, 2020 at 10:39:19PM -0400, Steven Rostedt wrote:
> What's so damn special about alloc_percpu()? It's definitely not a fast
> path. And it's not used often.
Okay, I fixed it in the percpu code. It is definitly not a nice
solution, but having to call vmalloc_sync_mappings/unmappings() is not a
nice solution at any place in the code. Here is the patch which fixes
this issue for me. I am also not sure what to put in the Fixes tag, as
it is related to tracing code accessing per-cpu data from the page-fault
handler, not sure when this got introduced. Maybe someone else can
provide a meaningful Fixes- or stable tag.
I also have an idea in mind how to make this all more robust and get rid
of the vmalloc_sync_mappings/unmappings() interface, will show more when
I know it works the way I think it does.
Regards,
Joerg
From c616a9a09499f9c9d682775767d3de7db81fb2ed Mon Sep 17 00:00:00 2001
From: Joerg Roedel <jroedel@suse.de>
Date: Mon, 4 May 2020 17:11:41 +0200
Subject: [PATCH] percpu: Sync vmalloc mappings in pcpu_alloc() and
free_percpu()
Sync the vmalloc mappings for all page-tables in the system when
allocating and freeing per-cpu memory. This is necessary for
architectures which use page-faults on vmalloc areas.
The page-fault handlers accesses per-cpu data when tracing is enabled,
and fauling again in the page-fault handler on a vmalloc'ed per-cpu area
will result in a recursive fault.
Signed-off-by: Joerg Roedel <jroedel@suse.de>
---
mm/percpu.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
diff --git a/mm/percpu.c b/mm/percpu.c
index d7e3bc649f4e..6ab035bc6977 100644
--- a/mm/percpu.c
+++ b/mm/percpu.c
@@ -1710,6 +1710,20 @@ static void __percpu *pcpu_alloc(size_t size, size_t align, bool reserved,
trace_percpu_alloc_percpu(reserved, is_atomic, size, align,
chunk->base_addr, off, ptr);
+ /*
+ * The per-cpu buffers might be allocated in the vmalloc area of the
+ * address space. When the architecture allows faulting on the vmalloc
+ * area and the memory allocated here is accessed in the page-fault
+ * handler, the vmalloc area fault may be recursive and could never be
+ * resolved.
+ * This happens for example in the tracing code which allocates per-cpu
+ * and accesses them when tracing page-faults.
+ * To prevent this, make sure the per-cpu buffers allocated here are
+ * mapped in all PGDs so that the page-fault handler will never fault
+ * again on them.
+ */
+ vmalloc_sync_mappings();
+
return ptr;
fail_unlock:
@@ -1958,6 +1972,12 @@ void free_percpu(void __percpu *ptr)
trace_percpu_free_percpu(chunk->base_addr, off, ptr);
+ /*
+ * See comment at the vmalloc_sync_mappings() call in pcpu_alloc() for
+ * why this is necessary.
+ */
+ vmalloc_sync_unmappings();
+
spin_unlock_irqrestore(&pcpu_lock, flags);
if (need_balance)
--
2.12.3
next prev parent reply other threads:[~2020-05-04 15:12 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-29 9:48 [RFC][PATCH] x86/mm: Sync all vmalloc mappings before text_poke() Steven Rostedt
2020-04-29 10:59 ` Joerg Roedel
2020-04-29 12:28 ` Steven Rostedt
2020-04-29 14:07 ` Steven Rostedt
2020-04-29 14:10 ` Joerg Roedel
2020-04-29 14:32 ` Steven Rostedt
2020-04-29 15:44 ` Peter Zijlstra
2020-04-29 16:17 ` Joerg Roedel
2020-04-29 16:20 ` Joerg Roedel
2020-04-29 16:52 ` Steven Rostedt
2020-04-29 17:29 ` Mathieu Desnoyers
2020-04-29 18:51 ` Peter Zijlstra
2020-04-30 14:11 ` Joerg Roedel
2020-04-30 14:50 ` Joerg Roedel
2020-04-30 15:20 ` Mathieu Desnoyers
2020-04-30 16:16 ` Steven Rostedt
2020-04-30 16:18 ` Mathieu Desnoyers
2020-04-30 16:30 ` Steven Rostedt
2020-04-30 16:35 ` Mathieu Desnoyers
2020-04-30 15:23 ` Mathieu Desnoyers
2020-04-30 16:12 ` Steven Rostedt
2020-04-30 16:11 ` Steven Rostedt
2020-04-30 16:16 ` Mathieu Desnoyers
2020-04-30 16:25 ` Steven Rostedt
2020-04-30 19:14 ` Joerg Roedel
2020-05-01 1:13 ` Steven Rostedt
2020-05-01 2:26 ` Mathieu Desnoyers
2020-05-01 2:39 ` Steven Rostedt
2020-05-01 10:16 ` Joerg Roedel
2020-05-01 13:35 ` Mathieu Desnoyers
2020-05-04 15:12 ` Joerg Roedel [this message]
2020-05-04 15:28 ` [PATCH] percpu: Sync vmalloc mappings in pcpu_alloc() and free_percpu() Mathieu Desnoyers
2020-05-04 15:31 ` Joerg Roedel
2020-05-04 15:38 ` Mathieu Desnoyers
2020-05-04 15:51 ` Joerg Roedel
2020-05-04 17:04 ` Steven Rostedt
2020-05-04 17:40 ` Steven Rostedt
2020-05-04 18:38 ` Joerg Roedel
2020-05-04 19:10 ` Steven Rostedt
2020-05-05 12:31 ` [PATCH] tracing: Call vmalloc_sync_mappings() after alloc_percpu() Joerg Roedel
2020-05-06 15:17 ` Steven Rostedt
2020-05-08 14:42 ` Joerg Roedel
2020-05-04 20:25 ` [PATCH] percpu: Sync vmalloc mappings in pcpu_alloc() and free_percpu() Peter Zijlstra
2020-05-04 20:43 ` Steven Rostedt
2020-05-01 4:20 ` [RFC][PATCH] x86/mm: Sync all vmalloc mappings before text_poke() Steven Rostedt
2020-05-01 13:22 ` Mathieu Desnoyers
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=20200504151236.GI8135@suse.de \
--to=jroedel@suse.de \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@amacapital.net \
--cc=mathieu.desnoyers@efficios.com \
--cc=mingo@kernel.org \
--cc=peterz@infradead.org \
--cc=rafael.j.wysocki@intel.com \
--cc=rostedt@goodmis.org \
--cc=shile.zhang@linux.alibaba.com \
--cc=tglx@linutronix.de \
--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.