netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Alexei Starovoitov <alexei.starovoitov@gmail.com>
Cc: Andrii Nakryiko <andriin@fb.com>, bpf <bpf@vger.kernel.org>,
	Networking <netdev@vger.kernel.org>,
	Alexei Starovoitov <ast@fb.com>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 1/3] libbpf: support libbpf-provided extern variables
Date: Thu, 12 Dec 2019 21:51:32 -0800	[thread overview]
Message-ID: <CAEf4BzYpcEWpCvxuv9Jyi2svNN9vezrzystkp8+DSCqywL_YMA@mail.gmail.com> (raw)
In-Reply-To: <20191213050739.xt4wnofdwf66gcrw@ast-mbp>

On Thu, Dec 12, 2019 at 9:11 PM Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
>
> On Tue, Dec 10, 2019 at 10:50:00PM -0800, Andrii Nakryiko wrote:
> > +static int set_ext_value_tri(struct extern_desc *ext, void *ext_val,
> > +                          char value)
> > +{
> > +     switch (ext->type) {
> > +     case EXT_BOOL:
> > +             if (value == 'm') {
> > +                     pr_warn("extern %s=%c should be tristate or char\n",
> > +                             ext->name, value);
> > +                     return -EINVAL;
> > +             }
> > +             *(bool *)ext_val = value == 'y' ? true : false;
>
> may be check for strict y/n ?

Can't be anything else due to `case 'y': case 'n': case 'm':` check in
the caller.


>
> > +             break;
> > +     case EXT_TRISTATE:
> > +             if (value == 'y')
> > +                     *(enum libbpf_tristate *)ext_val = TRI_YES;
> > +             else if (value == 'm')
> > +                     *(enum libbpf_tristate *)ext_val = TRI_MODULE;
> > +             else /* value == 'n' */
> > +                     *(enum libbpf_tristate *)ext_val = TRI_NO;
>
> same here ?
>
> > +             break;
> > +     case EXT_CHAR:
> > +             *(char *)ext_val = value;
> > +             break;
> > +     case EXT_UNKNOWN:
> > +     case EXT_INT:
> > +     case EXT_CHAR_ARR:
>
> why enumerate them when there is a default ?

Because compiler is too smart and strict. Otherwise getting:

libbpf.c: In function ‘set_ext_value_tri’:
libbpf.c:982:2: error: enumeration value ‘EXT_UNKNOWN’ not handled in
switch [-Werror=switch-enum]
  switch (ext->type) {
  ^~~~~~
libbpf.c:982:2: error: enumeration value ‘EXT_INT’ not handled in
switch [-Werror=switch-enum]
libbpf.c:982:2: error: enumeration value ‘EXT_CHAR_ARR’ not handled in
switch [-Werror=switch-enum]

>
> > +static int set_ext_value_str(struct extern_desc *ext, void *ext_val,
> > +                          const char *value)
> > +{
> > +     size_t len;
> > +
> > +     if (ext->type != EXT_CHAR_ARR) {
> > +             pr_warn("extern %s=%s should char array\n", ext->name, value);
> > +             return -EINVAL;
> > +     }
> > +
> > +     len = strlen(value);
> > +     if (value[len - 1] != '"') {
> > +             pr_warn("extern '%s': invalid string config '%s'\n",
> > +                     ext->name, value);
> > +             return -EINVAL;
> > +     }
> > +
> > +     /* strip quotes */
> > +     len -= 2;
> > +     if (len + 1 > ext->sz) {
> > +             pr_warn("extern '%s': too long string config %s (%zu bytes), up to %d expected\n",
> > +                     ext->name, value, len + 1, ext->sz);
> > +             return -EINVAL;
>
> may be print warning and truncate instead of hard error?

Could do. I erred on the side of being strict. I don't mind relaxing
this, though.

>
> > +static bool is_ext_value_in_range(const struct extern_desc *ext, __u64 v)
> > +{
> > +     int bit_sz = ext->sz * 8;
> > +
> > +     if (ext->sz == 8)
> > +             return true;
> > +
> > +     if (ext->is_signed)
> > +             return v + (1ULL << (bit_sz - 1)) < (1ULL << bit_sz);
> > +     else
> > +             return (v >> bit_sz) == 0;
>
> a comment would be helpful.

will add

>
> > +             ext_val = data + ext->data_off;
> > +             value = sep + 1;
> > +
> > +             switch (*value) {
> > +             case 'y': case 'n': case 'm':
>
> I don't think config.gz has 'n', but it's good to have it here.
>
> > -                     } else if (strcmp(name, ".data") == 0) {
> > +                     } else if (strcmp(name, DATA_SEC) == 0) {
> >                               obj->efile.data = data;
> >                               obj->efile.data_shndx = idx;
> > -                     } else if (strcmp(name, ".rodata") == 0) {
> > +                     } else if (strcmp(name, RODATA_SEC) == 0) {
>
> such cleanup changes should be in separate patch.

Ok, will split out. Needed that for .extern, decided to complete for
others in the same go.

>
> > +             if (strcmp(ext->name, "LINUX_KERNEL_VERSION") == 0) {
> > +                     void *ext_val = data + ext->data_off;
> > +                     __u32 kver = get_kernel_version();
> > +
> > +                     if (!kver) {
> > +                             pr_warn("failed to get kernel version\n");
> > +                             return -EINVAL;
> > +                     }
> > +                     err = set_ext_value_num(ext, ext_val, kver);
>
> I think it should work when kern_ver is not 'int'.
> Could you add a test for u64 ?
> Or it will fail on big endian?
>

Yeah, it is handled inside set_ext_value_num just the same as any
CONFIG_xxx integers. I will make sure that test_core_extern and
test_skeleton use both u32 and u64.

  reply	other threads:[~2019-12-13  5:51 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-12-11  6:49 [PATCH v2 bpf-next 0/3] Add libbpf-provided extern variables support Andrii Nakryiko
2019-12-11  6:50 ` [PATCH v2 bpf-next 1/3] libbpf: support libbpf-provided extern variables Andrii Nakryiko
2019-12-13  5:11   ` Alexei Starovoitov
2019-12-13  5:51     ` Andrii Nakryiko [this message]
2019-12-11  6:50 ` [PATCH v2 bpf-next 2/3] bpftool: generate externs datasec in BPF skeleton Andrii Nakryiko
2019-12-11  6:50 ` [PATCH v2 bpf-next 3/3] selftests/bpf: add tests for libbpf-provided externs Andrii Nakryiko

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=CAEf4BzYpcEWpCvxuv9Jyi2svNN9vezrzystkp8+DSCqywL_YMA@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=alexei.starovoitov@gmail.com \
    --cc=andriin@fb.com \
    --cc=ast@fb.com \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=kernel-team@fb.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).