summaryrefslogtreecommitdiff
path: root/arch/sparc/lib/U1memcpy.S
diff options
context:
space:
mode:
authorRob Gardner <rob.gardner@oracle.com>2015-12-23 04:16:07 (GMT)
committerDavid S. Miller <davem@davemloft.net>2015-12-24 17:12:46 (GMT)
commit833526941f5945cf0b22a595bb8f3525b512f654 (patch)
tree58bafcc903afdaffb84c2b89c7868a2aa49a9e33 /arch/sparc/lib/U1memcpy.S
parent3f74306ac84cf7f2da2fdc87014fc455f5e67bad (diff)
downloadlinux-833526941f5945cf0b22a595bb8f3525b512f654.tar.xz
sparc64: Perf should save/restore fault info
There have been several reports of random processes being killed with a bus error or segfault during userspace stack walking in perf. One of the root causes of this problem is an asynchronous modification to thread_info fault_address and fault_code, which stems from a perf counter interrupt arriving during kernel processing of a "benign" fault, such as a TSB miss. Since perf_callchain_user() invokes copy_from_user() to read user stacks, a fault is not only possible, but probable. Validity checks on the stack address merely cover up the problem and reduce its frequency. The solution here is to save and restore fault_address and fault_code in perf_callchain_user() so that the benign fault handler is not disturbed by a perf interrupt. Signed-off-by: Rob Gardner <rob.gardner@oracle.com> Signed-off-by: Dave Aldridge <david.j.aldridge@oracle.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Diffstat (limited to 'arch/sparc/lib/U1memcpy.S')
0 files changed, 0 insertions, 0 deletions