[PATCH] arm64: ftrace: use HAVE_FUNCTION_GRAPH_RET_ADDR_PTR

[Mark Rutland]

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.