From: Jiri Olsa <olsajiri@gmail.com>
To: Song Liu <song@kernel.org>
Cc: 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, olsajiri@gmail.com, asavkov@redhat.com
Subject: Re: [PATCH bpf-next v9 1/4] bpf: Relax tracing prog recursive attach rules
Date: Sun, 17 Dec 2023 20:22:11 +0100 [thread overview]
Message-ID: <ZX9KY-uouFF1Doz3@krava> (raw)
In-Reply-To: <CAPhsuW4VJ-wS_Jh9VCMAvLtbd9djtDikApH4NYCo9+Jgqz8eLQ@mail.gmail.com>
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
jirka
>
> Thanks,
> Song
>
> > + } else if (tgt_prog->type == prog->type) {
> > + /*
> > + * To avoid potential call chain cycles, prevent attaching of a
> > + * program extension to another extension. It's ok to attach
> > + * fentry/fexit to extension program.
next prev parent reply other threads:[~2023-12-17 19:22 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 [this message]
2023-12-18 0:58 ` Song Liu
2023-12-18 7:47 ` Jiri Olsa
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=ZX9KY-uouFF1Doz3@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox