From: Jiri Olsa <olsajiri@gmail.com>
To: Song Liu <song@kernel.org>
Cc: Jiri Olsa <olsajiri@gmail.com>,
Dmitrii Dolgov <9erthalion6@gmail.com>,
bpf@vger.kernel.org, ast@kernel.org, daniel@iogearbox.net,
andrii@kernel.org, martin.lau@linux.dev, yonghong.song@linux.dev,
dan.carpenter@linaro.org, asavkov@redhat.com
Subject: Re: [PATCH bpf-next v9 1/4] bpf: Relax tracing prog recursive attach rules
Date: Mon, 18 Dec 2023 08:47:14 +0100 [thread overview]
Message-ID: <ZX_5AhpYjcX06feL@krava> (raw)
In-Reply-To: <CAPhsuW4SfDEPy3sxTTr2VPYCW7ysM+ACUHwzuAcniy9-cgan5A@mail.gmail.com>
On Sun, Dec 17, 2023 at 04:58:07PM -0800, Song Liu wrote:
> On Sun, Dec 17, 2023 at 11:22 AM Jiri Olsa <olsajiri@gmail.com> wrote:
> >
> > On Sat, Dec 16, 2023 at 05:31:21PM -0800, Song Liu wrote:
> > > On Fri, Dec 15, 2023 at 12:11 PM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
> > > [...]
> > > > diff --git a/include/linux/bpf.h b/include/linux/bpf.h
> > > > index eb447b0a9423..e7393674ab94 100644
> > > > --- a/include/linux/bpf.h
> > > > +++ b/include/linux/bpf.h
> > > > @@ -1414,6 +1414,7 @@ struct bpf_prog_aux {
> > > > bool dev_bound; /* Program is bound to the netdev. */
> > > > bool offload_requested; /* Program is bound and offloaded to the netdev. */
> > > > bool attach_btf_trace; /* true if attaching to BTF-enabled raw tp */
> > > > + bool attach_tracing_prog; /* true if tracing another tracing program */
> > > > bool func_proto_unreliable;
> > > > bool sleepable;
> > > > bool tail_call_reachable;
> > > > diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> > > > index 5e43ddd1b83f..bcc5d5ab0870 100644
> > > > --- a/kernel/bpf/syscall.c
> > > > +++ b/kernel/bpf/syscall.c
> > > > @@ -3040,8 +3040,10 @@ static void bpf_tracing_link_release(struct bpf_link *link)
> > > > bpf_trampoline_put(tr_link->trampoline);
> > > >
> > > > /* tgt_prog is NULL if target is a kernel function */
> > > > - if (tr_link->tgt_prog)
> > > > + if (tr_link->tgt_prog) {
> > > > bpf_prog_put(tr_link->tgt_prog);
> > > > + link->prog->aux->attach_tracing_prog = false;
> > > > + }
> > > > }
> > > >
> > > > static void bpf_tracing_link_dealloc(struct bpf_link *link)
> > > > @@ -3243,6 +3245,12 @@ static int bpf_tracing_prog_attach(struct bpf_prog *prog,
> > > > goto out_unlock;
> > > > }
> > > >
> > > > + /* Bookkeeping for managing the prog attachment chain */
> > > > + if (tgt_prog &&
> > > > + prog->type == BPF_PROG_TYPE_TRACING &&
> > > > + tgt_prog->type == BPF_PROG_TYPE_TRACING)
> > > > + prog->aux->attach_tracing_prog = true;
> > > > +
> > > > link->tgt_prog = tgt_prog;
> > > > link->trampoline = tr;
> > > >
> > > > diff --git a/kernel/bpf/verifier.c b/kernel/bpf/verifier.c
> > > > index 8e7b6072e3f4..f8c15ce8fd05 100644
> > > > --- a/kernel/bpf/verifier.c
> > > > +++ b/kernel/bpf/verifier.c
> > > > @@ -20077,6 +20077,7 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> > > > struct bpf_attach_target_info *tgt_info)
> > > > {
> > > > bool prog_extension = prog->type == BPF_PROG_TYPE_EXT;
> > > > + bool prog_tracing = prog->type == BPF_PROG_TYPE_TRACING;
> > > > const char prefix[] = "btf_trace_";
> > > > int ret = 0, subprog = -1, i;
> > > > const struct btf_type *t;
> > > > @@ -20147,10 +20148,21 @@ int bpf_check_attach_target(struct bpf_verifier_log *log,
> > > > bpf_log(log, "Can attach to only JITed progs\n");
> > > > return -EINVAL;
> > > > }
> > > > - if (tgt_prog->type == prog->type) {
> > > > - /* Cannot fentry/fexit another fentry/fexit program.
> > > > - * Cannot attach program extension to another extension.
> > > > - * It's ok to attach fentry/fexit to extension program.
> > > > + if (prog_tracing) {
> > > > + if (aux->attach_tracing_prog) {
> > > > + /*
> > > > + * Target program is an fentry/fexit which is already attached
> > > > + * to another tracing program. More levels of nesting
> > > > + * attachment are not allowed.
> > > > + */
> > > > + bpf_log(log, "Cannot nest tracing program attach more than once\n");
> > > > + return -EINVAL;
> > > > + }
> > >
> > > If we add
> > >
> > > + prog->aux->attach_tracing_prog = true;
> > >
> > > here. We don't need the changes in syscall.c, right?
> > >
> > > IOW, we set attach_tracing_prog at program load time, not attach time.
> > >
> > > Would this work?
> >
> > I think it'd work.. I can just think of a case where we'd not allow
> > to attach fentry program (3) to another fentry (2) even if it's not
> > attached, but just loaded, like:
> >
> >
> > load (fentry1 -> kernel function)
> >
> > load (fentry2 -> fentry1)
> > fentry2->attach_tracing_prog = true
> >
> > load (fentry3 -> fentry2)
> > if (fentry2->aux->attach_tracing_prog)
> > return -EINVAL
> >
> >
> > I guess it's corner case that does not make much sense, but still it
> > feels more natural to me to set it in attach time
>
> If we set attach_tracing_prog at attach time, the following will
> succeed:
>
> load (fentry1 -> kernel function)
> load (fentry2 -> fentry1)
> load (fentry3 -> fentry2)
> attach (fentry1)
> attach (fentry2)
> attach (fentry3)
>
> We can even make attach chain longer, as long as we load
> the chain first. This is really confusing to me. So I think we should
> set the flag at load() time.
>
> Does this make sense?
yes, I did not consider this option.. makes sense
thanks,
jirka
next prev parent reply other threads:[~2023-12-18 7:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-15 20:07 [PATCH bpf-next v9 0/4] Relax tracing prog recursive attach rules Dmitrii Dolgov
2023-12-15 20:07 ` [PATCH bpf-next v9 1/4] bpf: " Dmitrii Dolgov
2023-12-17 1:31 ` Song Liu
2023-12-17 19:22 ` Jiri Olsa
2023-12-18 0:58 ` Song Liu
2023-12-18 7:47 ` Jiri Olsa [this message]
2023-12-18 20:10 ` Dmitry Dolgov
2023-12-20 7:55 ` Dmitry Dolgov
2023-12-20 13:13 ` Dmitry Dolgov
2023-12-15 20:07 ` [PATCH bpf-next v9 2/4] selftests/bpf: Add test for recursive attachment of tracing progs Dmitrii Dolgov
2023-12-15 20:07 ` [PATCH bpf-next v9 3/4] bpf: Fix re-attachment branch in bpf_tracing_prog_attach Dmitrii Dolgov
2023-12-15 20:07 ` [PATCH bpf-next v9 4/4] selftests/bpf: Test re-attachment fix for bpf_tracing_prog_attach Dmitrii Dolgov
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=ZX_5AhpYjcX06feL@krava \
--to=olsajiri@gmail.com \
--cc=9erthalion6@gmail.com \
--cc=andrii@kernel.org \
--cc=asavkov@redhat.com \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=dan.carpenter@linaro.org \
--cc=daniel@iogearbox.net \
--cc=martin.lau@linux.dev \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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.