summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python/parallel-perf.py
diff options
context:
space:
mode:
authorShrikanth Hegde <sshegde@linux.ibm.com>2026-09-21 12:51:50 +0530
committerMadhavan Srinivasan <maddy@linux.ibm.com>2026-09-25 10:25:18 +0530
commitaf5f0870883ae4aea7f668d06cbb7ad0e12824c8 (patch)
treeac3e20ba4350ec2449d6f49666056d12bd8edd0c /tools/perf/scripts/python/parallel-perf.py
parent5e78442b76844e4d46b9cac5ed123b76807f30db (diff)
powerpc/ftrace: Don't restore r13 during ftrace_regs_caller
Michal reported a stack-protector failure and subsequent panic when running kernel builds. This was observed with full/lazy preemption. Initially it was suspected as KVM, but later turned out to be due to a bcc tool running in parallel. Issue was recreated using a bcc tool. For example, running below in parallel leads to crash. ./funccount sched* -d 100 and make -j 64 The same crash was observed when running kprobe for schedule() function, while simpler function tracer for schedule() didn't cause the crash. This helped to narrow it down to ftrace backed kprobes area. The crash occurs as follows: ftrace_regs_caller entry on CPU A | +-> save r13 = CPU A PACA into pt_regs | +-> call kprobe_ftrace_handler() | +-> ftrace_test_recursion_unlock() | +-> preempt_enable +-> task can schedule and migrate to CPU B +-> task resumes with live r13 = CPU B PACA | +-> REST_GPRS(2, 31) | +-> restore saved r13 = CPU A PACA | |-> The task then continues running on CPU B with r13 pointing | to CPU A's PACA. The stack-protector canary is accessed through the PACA. After the task migrates, CPU A may run a different task and update its PACA with that task's canary. Restoring the saved r13 then causes the migrated task's saved stack canary to be compared against the canary in CPU A's PACA, resulting in a stack-protector failure. Similarly, current is resolved through the PACA. With a stale r13, preempt_count() can access the state of the task referenced by CPU A's PACA instead of the task running on CPU B. This results in corrupted preempt-count warnings and scheduling-while-atomic failures. This path for example is called when using kprobes and parallel kernel builds can cause preemptions during ftrace_test_recursion_unlock. Do not restore r13 from the saved register frame. If the task did not migrate, the live r13 already has the saved value. If it migrated, the live r13 contains the correct PACA pointer for the CPU on which the task resumed. On PPC32, r13 is regular register. So do this fix only for PPC64 Fixes: 153086644fd1 ("powerpc/ftrace: Add support for -mprofile-kernel ftrace ABI") Reported-by: Michal Suchánek <msuchanek@suse.de> Closes: https://lore.kernel.org/all/aqKfsVArHHaIK6M9@kunlun.suse.cz/ Reviewed-by: Christophe Leroy (CS GROUP) <chleroy@kernel.org> Reviewed-by: Hari Bathini <hbathini@linux.ibm.com> Signed-off-by: Shrikanth Hegde <sshegde@linux.ibm.com> Tested-by: Samir Mulani <samir@linux.ibm.com> Signed-off-by: Madhavan Srinivasan <maddy@linux.ibm.com> Link: https://patch.msgid.link/20260921072151.35531-1-sshegde@linux.ibm.com
Diffstat (limited to 'tools/perf/scripts/python/parallel-perf.py')
0 files changed, 0 insertions, 0 deletions