Messages in this thread | | | Date | Thu, 30 Apr 2020 22:26:55 -0400 (EDT) | From | Mathieu Desnoyers <> | Subject | Re: [RFC][PATCH] x86/mm: Sync all vmalloc mappings before text_poke() |
| |
----- On Apr 30, 2020, at 9:13 PM, rostedt rostedt@goodmis.org wrote:
> [ Joerg, sending again this time not just to you. (hit reply to sender > and not reply to all). Feel free to resend what you wrote before to this ] > > On Thu, 30 Apr 2020 21:14:34 +0200 > Joerg Roedel <jroedel@suse.de> wrote: > >> And alloc_percpu() calls down into pcpu_alloc(), which allocates new >> percpu chunks using vmalloc() on x86. And there we are again in the >> vmalloc area. > > So after a vmalloc() is made, should the page tables be synced?
Why should it ? Usually, the page fault handler is able to resolve the resulting minor page faults lazily.
> > This is a rather subtle bug, and I don't think it should be the caller of > percpu_alloc() that needs to call vmalloc_sync_mappings().
Who said tracing was easy ? ;-)
> What's your suggestion for a fix?
I know the question is not addressed to me, but here are my 2 cents:
It's subtle because ftrace is tracing the page fault handler through tracepoints. It would not make sense to slow down all vmalloc or percpu_alloc() just because tracing recurses when tracing page faults.
I think the right approach to solve this is to call vmalloc_sync_mappings() before any vmalloc'd memory ends up being observable by instrumentation. This can be achieved by adding a vmalloc_sync_mappings call on tracepoint registration like I proposed in my patchset a few week ago:
https://lore.kernel.org/r/20200409193543.18115-2-mathieu.desnoyers@efficios.com
The tracers just have to make sure they perform their vmalloc'd memory allocation before registering the tracepoint which can touch it, else they need to issue vmalloc_sync_mappings() on their own before making the newly allocated memory observable by instrumentation.
This approach is not new: register_die_notifier() does exactly that today.
Thanks,
Mathieu
-- Mathieu Desnoyers EfficiOS Inc. http://www.efficios.com
| |