On Thu, Feb 2, 2023 at 11:50 AM Daniel Borkmann <daniel@xxxxxxxxxxxxx> wrote: > > On 2/2/23 9:36 AM, Xu Kuohai wrote: > > On 2/2/2023 12:34 AM, Florent Revest wrote: > >> This series adds ftrace direct call support to arm64. > >> This makes BPF tracing programs (fentry/fexit/fmod_ret/lsm) work on arm64. > >> > >> It is meant to apply on top of the arm64 tree which contains Mark Rutland's > >> series on CALL_OPS [1] under the for-next/ftrace tag. > >> > The first three patches consolidate the two existing ftrace APIs for registering > >> direct calls. They are split to make the reviewers lives easier but if it'd be a > >> preferred style, I'd be happy to squash them in the next revision. > >> Currently, there is both a _ftrace_direct and _ftrace_direct_multi API. Apart > >> from samples and selftests, there are no users of the _ftrace_direct API left > >> in-tree so this deletes it and renames the _ftrace_direct_multi API to > >> _ftrace_direct for simplicity. > >> > >> The main benefit of this refactoring is that, with the API that's left, an > >> ftrace_ops backing a direct call will only ever point to one direct call. We can > >> therefore store the direct called trampoline address in the ops (patch 4) and > >> look it up from the ftrace trampoline on arm64 (patch 7) in the case when the > >> destination would be out of reach of a BL instruction at the ftrace callsite. > >> (in this case, ftrace_caller acts as a lightweight intermediary trampoline) > >> > >> This series has been tested on both arm64 and x86_64 with: > >> 1- CONFIG_FTRACE_SELFTEST (cf: patch 6) > >> 2- samples/ftrace/*.ko (cf: patch 8) > >> 3- tools/testing/selftests/bpf/test_progs (both -t lsm and -t fentry_fexit) > > Thanks a ton for working on this! > > > so it's time to update DENYLIST.aarch64 to unblock tests that failed due to lack of direct call. That's a good point Xu, thanks! I'll update the deny list in my next revision. It looks like this series fixes *a lot* of these tests, so that's exciting. :) > +1, with regards to logistics, if possible it might be nice to eventually gets > this into a feature branch on arm64 tree, then we could pull it too from there > for bpf-next and hash out the BPF CI bits for arm64 in the meantime. I believe that Manu Bretelle already wired up the BPF CI for arm64, is there more work required ? Regarding the logistics, whatever works sgtm... :) I suppose it's up to Catalin or Will.
