[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAEf4BzY5ZMQJYwU5p-r4bnOcZLGsR1_1iY3-0KKnZyttRbyr6g@mail.gmail.com>
Date: Mon, 21 Oct 2019 12:18:33 -0700
From: Andrii Nakryiko <andrii.nakryiko@...il.com>
To: Carlos Antonio Neira Bustos <cneirabustos@...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: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
Powered by blists - more mailing lists