| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Thu, 19 Apr 2018 11:31:24 +0530
From: Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
To: Sandipan Das <sandipan@...ux.vnet.ibm.com>, acme@...nel.org
Cc: jolsa@...hat.com, linux-kernel@...r.kernel.org,
naveen.n.rao@...ux.vnet.ibm.com, ravi.bangoria@...ux.vnet.ibm.com,
sukadev@...ux.vnet.ibm.com, maynard@...ibm.com
Subject: Re: [PATCH v2 0/3] perf: Fixes for callchain ip handling on powerpc
On 04/18/2018 04:28 PM, Sandipan Das wrote:
> The first patch fixes the callchain ip filtering mechanism for powerpc
> from skipping entries in case the LR value is still valid and yet to
> be written to the stack frame. This was previously posted as an RFC
> here: https://lkml.org/lkml/2018/4/4/633
>
> The second patch fixes a crash caused by attempting to access an empty
> callchain.
>
> The third patch fixes a shell test which used to fail on powerpc as
> the back trace from perf output did not match the expected pattern.
> Also, because of the issue described in the first patch, some entries
> from the callchain were incorrectly skipped. So, this has also been
> readjusted to work with the fix in the first patch.
>
> v2:
> - Consider case when return address is in R0 as pointed out by Ravi.
> - Add another patch to fix crash when callchain is empty.
Looks good. For the series,
Tested-by: Ravi Bangoria <ravi.bangoria@...ux.ibm.com>
But there are few other cases, I've mentioned them in detail at the end,
which needs to be fixed. Arnaldo, if you are fine, can we push this series
and take care of other cases later on? No point in stretching this series.
I've used this simple test program to test it:
int i = 10000000;
void *ptr;
while (i--) {
ptr = malloc(i);
free(ptr);
}
Case 1:
Without Suka's and Sandipan's changes:
perf 9207 3034.786828: cycles:ppp:
10d66c power_pmu_enable (/lib/modules/4.17.0-rc1+/build/vmlinux)
2e4f24 perf_event_exec (/lib/modules/4.17.0-rc1+/build/vmlinux) <===== This one
4096cc setup_new_exec (/lib/modules/4.17.0-rc1+/build/vmlinux)
494f38 load_elf_binary (/lib/modules/4.17.0-rc1+/build/vmlinux)
40842c search_binary_handler (/lib/modules/4.17.0-rc1+/build/vmlinux)
40924c do_execveat_common.isra.13 (/lib/modules/4.17.0-rc1+/build/vmlinux)
40981c sys_execve (/lib/modules/4.17.0-rc1+/build/vmlinux)
1b9e0 system_call (/lib/modules/4.17.0-rc1+/build/vmlinux)
7fff9855b448 [unknown] ([unknown])
With only Suka's changes:
perf 9207 3034.786828: cycles:ppp:
10d66c power_pmu_enable (/lib/modules/4.17.0-rc1+/build/vmlinux)
4096cc setup_new_exec (/lib/modules/4.17.0-rc1+/build/vmlinux)
494f38 load_elf_binary (/lib/modules/4.17.0-rc1+/build/vmlinux)
40842c search_binary_handler (/lib/modules/4.17.0-rc1+/build/vmlinux)
40924c do_execveat_common.isra.13 (/lib/modules/4.17.0-rc1+/build/vmlinux)
40981c sys_execve (/lib/modules/4.17.0-rc1+/build/vmlinux)
1b9e0 system_call (/lib/modules/4.17.0-rc1+/build/vmlinux)
7fff9855b448 [unknown] ([unknown])
With both Suka's and Sandipan's changes:
perf 9207 3034.786828: cycles:ppp:
10d66c power_pmu_enable (/lib/modules/4.17.0-rc1+/build/vmlinux)
4096cc setup_new_exec (/lib/modules/4.17.0-rc1+/build/vmlinux)
494f38 load_elf_binary (/lib/modules/4.17.0-rc1+/build/vmlinux)
40842c search_binary_handler (/lib/modules/4.17.0-rc1+/build/vmlinux)
40924c do_execveat_common.isra.13 (/lib/modules/4.17.0-rc1+/build/vmlinux)
40981c sys_execve (/lib/modules/4.17.0-rc1+/build/vmlinux)
1b9e0 system_call (/lib/modules/4.17.0-rc1+/build/vmlinux)
7fff9855b448 [unknown] ([unknown])
perf_event_exec() is a valid entry, which is missing in last two output.
Case 2:
Without Suka's and Sandipan's changes:
1854.720942: 568814 cycles:ppp:
9cf3c _int_malloc (/usr/lib64/libc-2.26.so)
9f838 malloc (/usr/lib64/libc-2.26.so) <===== This one
0 [unknown] ([unknown])
624 main (/home/ravi/Workspace/malloc)
236a0 generic_start_main.isra.0 (/usr/lib64/libc-2.26.so)
23898 __libc_start_main (/usr/lib64/libc-2.26.so)
With only Suka's changes:
1854.720942: 568814 cycles:ppp:
9cf3c _int_malloc (/usr/lib64/libc-2.26.so)
0 [unknown] ([unknown])
624 main (/home/ravi/Workspace/malloc)
236a0 generic_start_main.isra.0 (/usr/lib64/libc-2.26.so)
23898 __libc_start_main (/usr/lib64/libc-2.26.so)
With both Suka's and Sandipan's changes:
1854.720942: 568814 cycles:ppp:
9cf3c _int_malloc (/usr/lib64/libc-2.26.so)
0 [unknown] ([unknown])
624 main (/home/ravi/Workspace/malloc)
236a0 generic_start_main.isra.0 (/usr/lib64/libc-2.26.so)
23898 __libc_start_main (/usr/lib64/libc-2.26.so)
malloc() is missing in last two output. Also, the pattern I've observed is,
all samples where malloc() is missing is followed by 0 [unknown] ([unknown]).
Thanks,
Ravi
Powered by blists - more mailing lists