Re: [PATCH] arm64: ftrace: use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR
From: Mark Rutland <mark.rutland@arm.com>
Date: 2021-10-29 15:08:25
On Thu, Oct 28, 2021 at 02:45:42PM +0100, Mark Rutland wrote:
I had a go with the selftests and there are some latent issues which show up on a pristine v5.15-rc4 (or v5.15-rc7), using defconfig + the ftrace selftest config fragment, including an OOM that could be a memory leak.
Later the tests hang in:
| [19] event tracing - enable/disable with subsystem level files
... and from trying:
| # ./ftracetest -vvv test.d/event/subsystem-enable.tc
... it seems to hang after the usual reset, on the first part of the
test, with the last output being:
| + . /root/ftrace/test.d/event/subsystem-enable.tc
| ++ echo 'sched:*'
| ++ yield
| ++ ping 127.0.0.1 -c 1
| PING 127.0.0.1 (127.0.0.1): 56 data bytes
| 64 bytes from 127.0.0.1: seq=0 ttl=64 time=2.442 ms
|
| --- 127.0.0.1 ping statistics ---
| 1 packets transmitted, 1 packets received, 0% packet loss
| round-trip min/avg/max = 2.442/2.442/2.442 ms
| +++ cat trace
| +++ grep -v '^#'
| +++ awk '{ print $5 }'
| +++ sort -u
| +++ wc -l In the end, this is because my test VM has 32 vCPUs and can create a tremendous amount of trace information. So much so that userspace spends an incredibly long time parsing it and trying to sort it. If I boot a 2 vCPU VM, this passes after a couple of seconds. I have a local patch to make the test more robust to this, which I'll send out in a bit. There are some other tests that want to scan the entire trace stream though, so practically it's necessary to run those with fewer CPUs. Thanks, Mark. _______________________________________________ linux-arm-kernel mailing list linux-arm-kernel@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-arm-kernel