[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.
> 
> I see the following warning:
> 
> | [15] Generic dynamic event - check if duplicate events are caught
> | ------------[ cut here ]------------
> | WARNING: CPU: 24 PID: 912 at kernel/trace/trace_eprobe.c:853 __trace_eprobe_create+0x3ec/0x71c
> | Modules linked in:
> | CPU: 24 PID: 912 Comm: ftracetest Not tainted 5.15.0-rc4 #1
> | Hardware name: linux,dummy-virt (DT)
> | pstate: 60400005 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
> | pc : __trace_eprobe_create+0x3ec/0x71c
> | lr : __trace_eprobe_create+0x3ec/0x71c
> | sp : ffff80001370bb60
> | x29: ffff80001370bb60 x28: ffff5ee1944cc299 x27: ffff80001370bc28
> | x26: 00000000000001c8 x25: ffffa8db50eece78 x24: 0000000000000010
> | x23: ffffa8db50eece48 x22: 00000000ffffffed x21: 0000000000000003
> | x20: ffff5ee1944cc008 x19: ffffa8db4fd2e398 x18: 0000000000000000
> | x17: 7473753a29656d61 x16: 6e656c6966242830 x15: 2b3d656c69662074
> | x14: 616e65706f5f7265 x13: 676e69727473753a x12: 29656d616e656c69
> | x11: 0000000000000003 x10: 0101010101010101 x9 : ffffa8db4edda690
> | x8 : 7f7f7f7f7f7f7f7f x7 : 726b6b6062727872 x6 : 1a171a17020d001f
> | x5 : 1f000d02171a171a x4 : ffff5ee18d2b3900 x3 : ffffa8db50eece48
> | x2 : 0000000000000000 x1 : ffff5ee18d2b3900 x0 : ffff5ee18d2b3900
> | Call trace:
> |  __trace_eprobe_create+0x3ec/0x71c
> |  trace_probe_create+0x90/0xb0
> |  eprobe_dyn_event_create+0x1c/0x30
> |  create_dyn_event+0x74/0x114
> |  trace_parse_run_command+0x104/0x7d0
> |  dyn_event_write+0x1c/0x30
> |  vfs_write+0xfc/0x290
> |  ksys_write+0x74/0x100
> |  __arm64_sys_write+0x28/0x3c
> |  invoke_syscall+0x50/0x120
> |  el0_svc_common.constprop.0+0x104/0x124
> |  do_el0_svc+0x34/0x9c
> |  el0_svc+0x2c/0x90
> |  el0t_64_sync_handler+0xa8/0x12c
> |  el0t_64_sync+0x1a0/0x1a4
> | ---[ end trace 24f9a9e45b173e0b ]---
> |         [FAIL]
> 
> That seems to be the following in __trace_eprobe_create():
> 
> | mutex_lock(&event_mutex);
> | event_call = find_and_get_event(sys_name, sys_event);
> | ep = alloc_event_probe(group, event, event_call, argc - 2);
> | mutex_unlock(&event_mutex);
> | 
> | if (IS_ERR(ep)) {
> | 	ret = PTR_ERR(ep);
> | 	/* This must return -ENOMEM, else there is a bug */
> | 	WARN_ON_ONCE(ret != -ENOMEM);
> | 	ep = NULL;
> | 	goto error;
> | }
> 
> ... but I haven't yet dug into exactly why that's returning an
> unexpected error code.

It turns out this is a latent bug when the user requests a bogus event,
find_and_get_event() fails and returns NULL, causing alloc_event_probe()
to return -ENODEV.

The right thing to do there is to check the result of
find_and_get_event(); I have a local patch for that.

The reason that was bogus at all was that I didn't have
CONFIG_FTRACE_SYSCALLS selected and so `syscalls:sys_enter_openat`
didn't exist. I didn't have that selected because it wasn't in the
Kconfig fragment for the ftrace selftests; I have a local patch for
that.

I'm still working through the other bits. If I sovle that shortly I'll
send that as a series with the two patches above, otherwise I'll send
those out on their own.

Thanks,
Mark.