----- On Apr 30, 2020, at 9:13 PM, rostedt rost...@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 <jroe...@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.desnoy...@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
