All of lore.kernel.org
 help / color / mirror / Atom feed
From: Martin KaFai Lau <kafai@fb.com>
To: Hou Tao <houtao1@huawei.com>
Cc: Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>, <netdev@vger.kernel.org>,
	<bpf@vger.kernel.org>
Subject: Re: [PATCH bpf-next 3/5] bpf: do .test_run in dummy BPF STRUCT_OPS
Date: Fri, 1 Oct 2021 12:09:02 -0700	[thread overview]
Message-ID: <20211001190902.c5zmrxedytkcrc3l@kafai-mbp> (raw)
In-Reply-To: <89ce4b1c-6ea6-80b9-ec2f-5a6d49dd591b@huawei.com>

On Thu, Sep 30, 2021 at 07:05:41PM +0800, Hou Tao wrote:
> >> diff --git a/net/bpf/bpf_dummy_struct_ops.c b/net/bpf/bpf_dummy_struct_ops.c
> >> index 1249e4bb4ccb..da77736cd093 100644
> >> --- a/net/bpf/bpf_dummy_struct_ops.c
> >> +++ b/net/bpf/bpf_dummy_struct_ops.c
> >> @@ -10,12 +10,188 @@
> >>  
> >>  extern struct bpf_struct_ops bpf_bpf_dummy_ops;
> >>  
> >> +static const struct btf_type *dummy_ops_state;
> >> +
> >> +static struct bpf_dummy_ops_state *
> >> +init_dummy_ops_state(const union bpf_attr *kattr)
> >> +{
> >> +	__u32 size_in;
> >> +	struct bpf_dummy_ops_state *state;
> >> +	void __user *data_in;
> >> +
> >> +	size_in = kattr->test.data_size_in;
> > These are the args for the test functions?  Using ctx_in/ctx_size_in
> > and ctx_out/ctx_size_out instead should be more consistent
> > with other bpf_prog_test_run* in test_run.c.
> Yes, there are args. I had think about using ctx_in/ctx_out, but I didn't
> because I thought the program which using ctx_in/ctx_out only has
> one argument (namely bpf_context *), but the bpf_dummy_ops::init
> may have multiple arguments. Anyway I will check it again and use
> ctx_in/ctx_out if possible.
got it.

ctx_in could have multiple args.
I was more thinking on the muliple arg test also. Potentially some of them
are just integers, e.g. 

int test2(struct bpf_dummy_ops_state *state, char a, short b, int c, long d)
{

}

All args can be put in ctx_in like bpf_prog_test_run_raw_tp().
Take a look at raw_tp_test_run.c.  Although it is not strictly
necessary to use u64 for all args in the struct_ops test
because the struct_ops test still wants to prepare the
trampoline to catch the return value issue...etc,  passing
an array of u64 args in ctx_in should make it easier to program
the userspace and optimizing the ctx_in based on the sizeof each
arg seems not gaining much as a test also.

For "struct bpf_dummy_ops_state *state", instead of making an
exception to pass ptr arg in data_in,  the user ptr can be directly
passed as a u64 stored in ctx_in also, then there is no need to use
data_in or data_size_in.  If it is needed, the userspace's
sizeof(struct bpf_dummy_ops_state) can be found from the
prog->aux->btf.
There is no need to use data_out/data_out_size also, just directly
copy it back to the same user ptr stored in ctx_in.

  reply	other threads:[~2021-10-01 19:09 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-28  2:52 [PATCH bpf-next 0/5] introduce dummy BPF STRUCT_OPS Hou Tao
2021-09-28  2:52 ` [PATCH bpf-next 1/5] bpf: add dummy BPF STRUCT_OPS for test purpose Hou Tao
2021-09-28  2:52 ` [PATCH bpf-next 2/5] bpf: factor out a helper to prepare trampoline for struct_ops prog Hou Tao
2021-09-29 17:56   ` Martin KaFai Lau
2021-09-30 10:17     ` Hou Tao
2021-10-01 17:39       ` Martin KaFai Lau
2021-09-28  2:52 ` [PATCH bpf-next 3/5] bpf: do .test_run in dummy BPF STRUCT_OPS Hou Tao
2021-09-29 18:55   ` Martin KaFai Lau
2021-09-30 11:05     ` Hou Tao
2021-10-01 19:09       ` Martin KaFai Lau [this message]
2021-09-28  2:52 ` [PATCH bpf-next 4/5] bpf: hook .test_run for struct_ops program Hou Tao
2021-09-28  2:52 ` [PATCH bpf-next 5/5] selftests/bpf: test return value handling for struct_ops prog Hou Tao
2021-09-28 23:19   ` Andrii Nakryiko
2021-09-30 11:08     ` Hou Tao

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=20211001190902.c5zmrxedytkcrc3l@kafai-mbp \
    --to=kafai@fb.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=houtao1@huawei.com \
    --cc=netdev@vger.kernel.org \
    /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.