Skip to content

Commit 11f5efc

Browse files
committed
tracing: Add a vmalloc_sync_mappings() for safe measure
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 763802b ("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/[email protected] Cc: [email protected] Fixes: 737223f ("tracing: Consolidate buffer allocation code") Reported-by: "Tzvetomir Stoyanov (VMware)" <[email protected]> Suggested-by: Joerg Roedel <[email protected]> Signed-off-by: Steven Rostedt (VMware) <[email protected]>
1 parent d16a8c3 commit 11f5efc

File tree

1 file changed

+13
-0
lines changed

1 file changed

+13
-0
lines changed

kernel/trace/trace.c

Lines changed: 13 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -8525,6 +8525,19 @@ static int allocate_trace_buffers(struct trace_array *tr, int size)
85258525
*/
85268526
allocate_snapshot = false;
85278527
#endif
8528+
8529+
/*
8530+
* Because of some magic with the way alloc_percpu() works on
8531+
* x86_64, we need to synchronize the pgd of all the tables,
8532+
* otherwise the trace events that happen in x86_64 page fault
8533+
* handlers can't cope with accessing the chance that a
8534+
* alloc_percpu()'d memory might be touched in the page fault trace
8535+
* event. Oh, and we need to audit all other alloc_percpu() and vmalloc()
8536+
* calls in tracing, because something might get triggered within a
8537+
* page fault trace event!
8538+
*/
8539+
vmalloc_sync_mappings();
8540+
85288541
return 0;
85298542
}
85308543

0 commit comments

Comments
 (0)