From: Martin KaFai Lau <martin.lau@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
Andrii Nakryiko <andrii@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Yonghong Song <yonghong.song@linux.dev>,
Amery Hung <ameryhung@gmail.com>,
kernel-team@meta.com, bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next 3/6] selftests/test: test gen_prologue and gen_epilogue
Date: Mon, 19 Aug 2024 15:30:11 -0700 [thread overview]
Message-ID: <b3887fe5-6093-4829-ab4d-025dc05aff9d@linux.dev> (raw)
In-Reply-To: <82a85e54945e6832f5eed24b59dd8950941345c5.camel@gmail.com>
On 8/16/24 1:27 PM, Eduard Zingerman wrote:
> On Fri, 2024-08-16 at 10:27 -0700, Martin KaFai Lau wrote:
>
> [...]
>
>> Thanks for checking!
>>
>> I think the bpf_map__attach_struct_ops() is not done such that st_ops is NULL.
>>
>> It probably needs another tag in the SEC("syscall") program to tell which st_ops
>> map should be attached first before executing the "syscall" program.
>>
>> I like the idea of using the __xlated macro to check the patched prologue, ctx
>> pointer saving, and epilogue. I will add this test in the respin. I will keep
>> the current way in this patch to exercise syscall and the ops/func in st_ops for
>> now. We can iterate on it later and use it as an example on what supports are
>> needed on the test_loader side for st_ops map testing. On the repetitive-enough
>> to worth test_loader refactoring side, I suspect some of the existing st_ops
>> load-success/load-failure tests may be worth to look at also. Thoughts?
>
> You are correct, this happens because bpf_map__attach_struct_ops() is
> not called. Fortunately, the change for test_loader.c is not very big.
> Please check two patches in the attachment.
The patch looks good. I tried and it works. I will add it in the next respin.
That will help to cover the __xlated check on the instructions generated by
gen_pro/epilogue and also check the syscall return value for the common case.
Except the tail_call test which needs to load a struct_ops program that does
bpf_tail_call and another struct_ops program that was used in the prog_array.
These two struct_ops programs need to be used in two separate struct_ops maps to
be able to load. The way that test_loader attaching all maps in your patch will
fail because bpf_testmod does not support attaching more than one struct_ops map.
I don't want to further polish on the tail_call testing side. I will stay with
the current way to do the tail_call test which also allows the more regular
trampoline "unsigned long long *ctx" for the main struct_ops prog and also
allows using ctx_in in the SEC("syscall") prog.
Thanks.
next prev parent reply other threads:[~2024-08-19 22:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-13 18:49 [RFC PATCH bpf-next 0/6] bpf: Add gen_epilogue and allow kfunc call in pro/epilogue Martin KaFai Lau
2024-08-13 18:49 ` [RFC PATCH bpf-next 1/6] bpf: Add gen_epilogue to bpf_verifier_ops Martin KaFai Lau
2024-08-14 20:56 ` Eduard Zingerman
2024-08-15 22:14 ` Martin KaFai Lau
2024-08-17 22:25 ` Amery Hung
2024-08-13 18:49 ` [RFC PATCH bpf-next 2/6] bpf: Export bpf_base_func_proto Martin KaFai Lau
2024-08-13 18:49 ` [RFC PATCH bpf-next 3/6] selftests/test: test gen_prologue and gen_epilogue Martin KaFai Lau
2024-08-14 20:48 ` Eduard Zingerman
2024-08-15 23:41 ` Martin KaFai Lau
2024-08-16 0:23 ` Eduard Zingerman
2024-08-16 1:50 ` Eduard Zingerman
2024-08-16 17:27 ` Martin KaFai Lau
2024-08-16 20:27 ` Eduard Zingerman
2024-08-19 22:30 ` Martin KaFai Lau [this message]
2024-08-13 18:49 ` [RFC PATCH bpf-next 4/6] bpf: Add module parameter to " Martin KaFai Lau
2024-08-13 18:49 ` [RFC PATCH bpf-next 5/6] bpf: Allow pro/epilogue to call kfunc Martin KaFai Lau
2024-08-14 22:17 ` Eduard Zingerman
2024-08-15 23:47 ` Martin KaFai Lau
2024-08-13 18:49 ` [RFC PATCH bpf-next 6/6] selftests/bpf: Add kfunc call test in gen_prologue and gen_epilogue Martin KaFai Lau
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b3887fe5-6093-4829-ab4d-025dc05aff9d@linux.dev \
--to=martin.lau@linux.dev \
--cc=ameryhung@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=kernel-team@meta.com \
--cc=yonghong.song@linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.