[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20191022165036.GA22524@frodo.byteswizards.com>
Date: Tue, 22 Oct 2019 13:50:36 -0300
From: Carlos Antonio Neira Bustos <cneirabustos@...il.com>
To: Andrii Nakryiko <andrii.nakryiko@...il.com>
Cc: Yonghong Song <yhs@...com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"ebiederm@...ssion.com" <ebiederm@...ssion.com>,
"brouer@...hat.com" <brouer@...hat.com>,
"bpf@...r.kernel.org" <bpf@...r.kernel.org>
Subject: Re: [PATCH v14 4/5] tools/testing/selftests/bpf: Add self-tests for
new helper.
On Mon, Oct 21, 2019 at 12:18:33PM -0700, Andrii Nakryiko wrote:
> On Mon, Oct 21, 2019 at 12:14 PM Carlos Antonio Neira Bustos
> <cneirabustos@...il.com> wrote:
> >
> > On Mon, Oct 21, 2019 at 11:20:01AM -0700, Andrii Nakryiko wrote:
> > > On Sat, Oct 19, 2019 at 1:58 AM Yonghong Song <yhs@...com> wrote:
> > > >
> > > >
> > > >
> > > > On 10/17/19 8:00 AM, Carlos Neira wrote:
> > > > > Self tests added for new helper
> > > > >
> > > > > Signed-off-by: Carlos Neira <cneirabustos@...il.com>
> > > > > ---
> > > > > .../bpf/prog_tests/get_ns_current_pid_tgid.c | 96 +++++++++++++++++++
> > > > > .../bpf/progs/get_ns_current_pid_tgid_kern.c | 53 ++++++++++
> > >
> > > It looks like typical naming convention is:
> > >
> > > prog_test/<something>.c
> > > progs/test_<something>.c
> > >
> > > Let's keep this consistent. I'm about to do a bit smarter Makefile
> > > that will capture this convention, so it's good to have less exception
> > > to create. Thanks!
> > >
> > > Otherwise, besides what Yonghong mentioned, this look good to me.
> > >
> > >
> > > > > 2 files changed, 149 insertions(+)
> > > > > create mode 100644 tools/testing/selftests/bpf/prog_tests/get_ns_current_pid_tgid.c
> > > > > create mode 100644 tools/testing/selftests/bpf/progs/get_ns_current_pid_tgid_kern.c
> > > > >
> > >
> > > [...]
> > >
> > > > > + prog = bpf_object__find_program_by_title(obj, probe_name);
> > > > > + if (CHECK(!prog, "find_probe",
> > > > > + "prog '%s' not found\n", probe_name))
> > > > > + goto cleanup;
> > > > > +
> > > > > + bpf_program__set_type(prog, BPF_PROG_TYPE_RAW_TRACEPOINT);
> > > >
> > > > Do we need this? I thought libbpf should automatically
> > > > infer program type from section name?
> > >
> > > We used to, until the patch set that Daniel landed today. Now it can be dropped.
> > >
> > > >
> > > > > +
> > > > > + load_attr.obj = obj;
> > > > > + load_attr.log_level = 0;
> > > > > + load_attr.target_btf_path = NULL;
> > > > > + err = bpf_object__load_xattr(&load_attr);
> > > > > + if (CHECK(err, "obj_load",
> > > > > + "failed to load prog '%s': %d\n",
> > > > > + probe_name, err))
> > > > > + goto cleanup;
> > > >
> > >
> > > [...]
> >
> > Thanks Andrii,
> > I have a doubt, I don't find in prog_tests/rdonly_map.c where is "test_rdo.bss" defined ?, is called in line 43 but I'm missing how to is it used as I don't see it defined.
> >
>
> This map is created by libbpf implicitly from global variables used by
> BPF object. You just look it up by name, set its value to whatever you
> need global variables to be set up to, and that value will be
> available to BPF program. From BPF program side, when you update
> global variable, that value can be read from user space using that
> same test_rdo.bss map. Does it make sense?
>
> > Bests
Thanks for the explanation Andrii, now it works!.
Powered by blists - more mailing lists