All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andrii Nakryiko <andrii.nakryiko@gmail.com>
To: Dave Marchevsky <davemarchevsky@fb.com>
Cc: Andrii Nakryiko <andrii@kernel.org>, bpf <bpf@vger.kernel.org>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Kernel Team <kernel-team@fb.com>
Subject: Re: [PATCH v2 bpf-next 7/9] libbpf: complete SEC() table unification for BPF_APROG_SEC/BPF_EAPROG_SEC
Date: Wed, 22 Sep 2021 15:12:31 -0700	[thread overview]
Message-ID: <CAEf4BzZXdnNWePXevV8UPySquFxnWPZtejdXdfBY-RG79o9YOA@mail.gmail.com> (raw)
In-Reply-To: <CAEf4BzZsbJBeqwZu8_pH=KQXwOSTyMRq=2K8=cnGSwzv2hPcfQ@mail.gmail.com>

On Wed, Sep 22, 2021 at 2:55 PM Andrii Nakryiko
<andrii.nakryiko@gmail.com> wrote:
>
> On Tue, Sep 21, 2021 at 6:42 PM Dave Marchevsky <davemarchevsky@fb.com> wrote:
> >
> > On 9/20/21 7:43 PM, Andrii Nakryiko wrote:
> > > Complete SEC() table refactoring towards unified form by rewriting
> > > BPF_APROG_SEC and BPF_EAPROG_SEC definitions with
> > > SEC_DEF(SEC_ATTACHABLE_OPT) (for optional expected_attach_type) and
> > > SEC_DEF(SEC_ATTACHABLE) (mandatory expected_attach_type), respectively.
> > > Drop BPF_APROG_SEC, BPF_EAPROG_SEC, and BPF_PROG_SEC_IMPL macros after
> > > that, leaving SEC_DEF() macro as the only one used.
> > >
> > > Signed-off-by: Andrii Nakryiko <andrii@kernel.org>
> > > ---
> > >  tools/lib/bpf/libbpf.c | 136 +++++++++++------------------------------
> > >  1 file changed, 35 insertions(+), 101 deletions(-)
> > >
> > > diff --git a/tools/lib/bpf/libbpf.c b/tools/lib/bpf/libbpf.c
> > > index 734be7dc52a0..56082865ceff 100644
> > > --- a/tools/lib/bpf/libbpf.c
> > > +++ b/tools/lib/bpf/libbpf.c
> > > @@ -7959,32 +7959,6 @@ void bpf_program__set_expected_attach_type(struct bpf_program *prog,
> > >       prog->expected_attach_type = type;
> > >  }
> > >
> > > -#define BPF_PROG_SEC_IMPL(string, ptype, eatype, eatype_optional,        \
> > > -                       attachable, attach_btf)                           \
> > > -     {                                                                   \
> > > -             .sec = string,                                              \
> > > -             .prog_type = ptype,                                         \
> > > -             .expected_attach_type = eatype,                             \
> > > -             .cookie = (long) (                                          \
> > > -                     (eatype_optional ? SEC_EXP_ATTACH_OPT : 0) |   \
> > > -                     (attachable ? SEC_ATTACHABLE : 0) |                 \
> > > -                     (attach_btf ? SEC_ATTACH_BTF : 0)                   \
> > > -             ),                                                          \
> > > -             .preload_fn = libbpf_preload_prog,                          \
> > > -     }
> > > -
> > > -/* Programs that can be attached. */
> > > -#define BPF_APROG_SEC(string, ptype, atype) \
> > > -     BPF_PROG_SEC_IMPL(string, ptype, atype, true, 1, 0)
> > > -
> > > -/* Programs that must specify expected attach type at load time. */
> > > -#define BPF_EAPROG_SEC(string, ptype, eatype) \
> > > -     BPF_PROG_SEC_IMPL(string, ptype, eatype, false, 1, 0)
> > > -
> > > -/* Programs that use BTF to identify attach point */
> > > -#define BPF_PROG_BTF(string, ptype, eatype) \
> > > -     BPF_PROG_SEC_IMPL(string, ptype, eatype, false, 0, 1)
> > > -
> >
> > Similar thoughts about comment usefulness as patch 6.
> >
>
> I'll add succinct comments to each SEC_xxx flag, trying to emphasize
> what it is about
>
> > >  #define SEC_DEF(sec_pfx, ptype, atype, flags, ...) {                     \
> > >       .sec = sec_pfx,                                                     \
> > >       .prog_type = BPF_PROG_TYPE_##ptype,                                 \
> > > @@ -8003,10 +7977,8 @@ static struct bpf_link *attach_iter(const struct bpf_program *prog, long cookie)
> > >
> > >  static const struct bpf_sec_def section_defs[] = {
> > >       SEC_DEF("socket",               SOCKET_FILTER, 0, SEC_NONE),
> > > -     BPF_EAPROG_SEC("sk_reuseport/migrate",  BPF_PROG_TYPE_SK_REUSEPORT,
> > > -                                             BPF_SK_REUSEPORT_SELECT_OR_MIGRATE),
> > > -     BPF_EAPROG_SEC("sk_reuseport",          BPF_PROG_TYPE_SK_REUSEPORT,
> > > -                                             BPF_SK_REUSEPORT_SELECT),
> > > +     SEC_DEF("sk_reuseport/migrate", SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT_OR_MIGRATE, SEC_ATTACHABLE),
> > > +     SEC_DEF("sk_reuseport",         SK_REUSEPORT, BPF_SK_REUSEPORT_SELECT, SEC_ATTACHABLE),
> >
> > Ah, I see that after this patch the alignment issue from patch 6 is better.
> > Nevermind then.
> >
> > >       SEC_DEF("kprobe/",              KPROBE, 0, SEC_NONE, attach_kprobe),
> > >       SEC_DEF("uprobe/",              KPROBE, 0, SEC_NONE),
> > >       SEC_DEF("kretprobe/",           KPROBE, 0, SEC_NONE, attach_kprobe),
> >
> > [...]
> >
> > > +     SEC_DEF("sk_skb/stream_parser", SK_SKB, BPF_SK_SKB_STREAM_PARSER, SEC_ATTACHABLE_OPT),
> > > +     SEC_DEF("sk_skb/stream_verdict",SK_SKB, BPF_SK_SKB_STREAM_VERDICT, SEC_ATTACHABLE_OPT),
> >
> > checkpatch really doesn't like the lack of space after comma here, I agree
> > with it.
>
> it was either this, or one extra tab for all other entries making
> every line longer still. But I guess I'll just do s/SEC_DEF/SECDEF/
> and get that space back :)
>

Nah, it looks too ugly, like a pile of letters. I'll leave it as is,
checkpatch.pl will have to deal with this ;)

> But keep in mind, checkpatch.pl is a guide, not a law.
>
> >
> > >       SEC_DEF("sk_skb",               SK_SKB, 0, SEC_NONE),
> > > -     BPF_APROG_SEC("sk_msg",                 BPF_PROG_TYPE_SK_MSG,
> > > -                                             BPF_SK_MSG_VERDICT),
> > > -     BPF_APROG_SEC("lirc_mode2",             BPF_PROG_TYPE_LIRC_MODE2,
> >
> > [...]
> >

  reply	other threads:[~2021-09-22 22:12 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-20 23:43 [PATCH v2 bpf-next 0/9] libbpf: stricter BPF program section name handling Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 1/9] selftests/bpf: normalize XDP section names in selftests Andrii Nakryiko
2021-09-21  4:55   ` Dave Marchevsky
2021-09-21 23:08     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 2/9] selftests/bpf: normalize SEC("classifier") usage Andrii Nakryiko
2021-09-21  5:20   ` Dave Marchevsky
2021-09-21 23:10     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 3/9] selftests/bpf: normalize all the rest SEC() uses Andrii Nakryiko
2021-09-21  5:41   ` Dave Marchevsky
2021-09-21 23:12     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 4/9] libbpf: refactor internal sec_def handling to enable pluggability Andrii Nakryiko
2021-09-22  0:42   ` Dave Marchevsky
2021-09-22 22:06     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 5/9] libbpf: reduce reliance of attach_fns on sec_def internals Andrii Nakryiko
2021-09-22  1:00   ` Dave Marchevsky
2021-09-20 23:43 ` [PATCH v2 bpf-next 6/9] libbpf: refactor ELF section handler definitions Andrii Nakryiko
2021-09-22  1:34   ` Dave Marchevsky
2021-09-22 21:54     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 7/9] libbpf: complete SEC() table unification for BPF_APROG_SEC/BPF_EAPROG_SEC Andrii Nakryiko
2021-09-22  1:42   ` Dave Marchevsky
2021-09-22 21:55     ` Andrii Nakryiko
2021-09-22 22:12       ` Andrii Nakryiko [this message]
2021-09-20 23:43 ` [PATCH v2 bpf-next 8/9] libbpf: add opt-in strict BPF program section name handling logic Andrii Nakryiko
2021-09-22  1:53   ` Dave Marchevsky
2021-09-22 21:57     ` Andrii Nakryiko
2021-09-20 23:43 ` [PATCH v2 bpf-next 9/9] selftests/bpf: switch sk_lookup selftests to strict SEC("sk_lookup") use Andrii Nakryiko
2021-09-22  2:37   ` Dave Marchevsky

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=CAEf4BzZXdnNWePXevV8UPySquFxnWPZtejdXdfBY-RG79o9YOA@mail.gmail.com \
    --to=andrii.nakryiko@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davemarchevsky@fb.com \
    --cc=kernel-team@fb.com \
    /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.