]> git.baikalelectronics.ru Git - kernel.git/commit
tracing: Add a vmalloc_sync_mappings() for safe measure
authorSteven Rostedt (VMware) <rostedt@goodmis.org>
Wed, 6 May 2020 14:36:18 +0000 (10:36 -0400)
committerSteven Rostedt (VMware) <rostedt@goodmis.org>
Thu, 7 May 2020 17:32:57 +0000 (13:32 -0400)
commitbdd8b651ed5e4c6fdad809fc568218612edb80e5
tree929e6ecc8dec198f556309b70b54c799dcc752fe
parent303d51c10c1d5047bec647896cc92b2ec4213b12
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 34e8e55ddf1d ("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: f9afedbe99bd1 ("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