From: Jiri Olsa <olsajiri@gmail.com>
To: Jordan Rife <jordan@jrife.io>
Cc: bpf@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
linux-s390@vger.kernel.org, x86@kernel.org,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
Andrii Nakryiko <andrii@kernel.org>,
Martin KaFai Lau <martin.lau@linux.dev>,
Puranjay Mohan <puranjay@kernel.org>,
Ilya Leoshkevich <iii@linux.ibm.com>,
Ingo Molnar <mingo@redhat.com>
Subject: Re: [RFC PATCH bpf-next 1/7] bpf: Set up update_prog scaffolding for bpf_tracing_link_lops
Date: Fri, 21 Nov 2025 17:34:54 +0100 [thread overview]
Message-ID: <aSCUrtsBrfS2iTkB@krava> (raw)
In-Reply-To: <20251118005305.27058-2-jordan@jrife.io>
On Mon, Nov 17, 2025 at 04:52:53PM -0800, Jordan Rife wrote:
SNIP
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index f62d61b6730a..b0da7c428a65 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -63,6 +63,8 @@ static DEFINE_IDR(map_idr);
> static DEFINE_SPINLOCK(map_idr_lock);
> static DEFINE_IDR(link_idr);
> static DEFINE_SPINLOCK(link_idr_lock);
> +/* Synchronizes access to prog between link update operations. */
> +static DEFINE_MUTEX(trace_link_mutex);
>
> int sysctl_unprivileged_bpf_disabled __read_mostly =
> IS_BUILTIN(CONFIG_BPF_UNPRIV_DEFAULT_OFF) ? 2 : 0;
> @@ -3562,11 +3564,77 @@ static int bpf_tracing_link_fill_link_info(const struct bpf_link *link,
> return 0;
> }
>
> +static int bpf_tracing_link_update_prog(struct bpf_link *link,
> + struct bpf_prog *new_prog,
> + struct bpf_prog *old_prog)
> +{
> + struct bpf_tracing_link *tr_link =
> + container_of(link, struct bpf_tracing_link, link.link);
> + struct bpf_attach_target_info tgt_info = {0};
> + int err = 0;
> + u32 btf_id;
> +
> + mutex_lock(&trace_link_mutex);
that seems too much, we could add link->mutex
> +
> + if (old_prog && link->prog != old_prog) {
> + err = -EPERM;
> + goto out;
> + }
> + old_prog = link->prog;
> + if (old_prog->type != new_prog->type ||
> + old_prog->expected_attach_type != new_prog->expected_attach_type) {
> + err = -EINVAL;
> + goto out;
> + }
> +
> + mutex_lock(&new_prog->aux->dst_mutex);
> +
> + if (!new_prog->aux->dst_trampoline ||
> + new_prog->aux->dst_trampoline->key != tr_link->trampoline->key) {
hum, would be easier (and still usefull) to allow just programs for the same function?
> + bpf_trampoline_unpack_key(tr_link->trampoline->key, NULL,
> + &btf_id);
> + /* If there is no saved target, or the target associated with
> + * this link is different from the destination specified at
> + * load time, we need to check for compatibility.
> + */
> + err = bpf_check_attach_target(NULL, new_prog, tr_link->tgt_prog,
> + btf_id, &tgt_info);
> + if (err)
> + goto out_unlock;
> + }
> +
> + err = bpf_trampoline_update_prog(&tr_link->link, new_prog,
> + tr_link->trampoline);
> + if (err)
> + goto out_unlock;
> +
> + /* Clear the trampoline, mod, and target prog from new_prog->aux to make
> + * sure the original attach destination is not kept alive after a
> + * program is (re-)attached to another target.
> + */
> + if (new_prog->aux->dst_prog)
> + bpf_prog_put(new_prog->aux->dst_prog);
> + bpf_trampoline_put(new_prog->aux->dst_trampoline);
would it be possible just to take tr->mutex and unlink/link
the programs, something like:
mutex_lock(&tr->mutex);
__bpf_trampoline_unlink_prog(old_prog)
__bpf_trampoline_link_prog(new_prog)
mutex_unlock(&tr->mutex);
I might be missing something but this way we wouldn't need
the arch chages in the following patches?
jirka
> + module_put(new_prog->aux->mod);
> +
> + new_prog->aux->dst_prog = NULL;
> + new_prog->aux->dst_trampoline = NULL;
> + new_prog->aux->mod = tgt_info.tgt_mod;
> + tgt_info.tgt_mod = NULL; /* Make module_put() below do nothing. */
> +out_unlock:
> + mutex_unlock(&new_prog->aux->dst_mutex);
> +out:
> + mutex_unlock(&trace_link_mutex);
> + module_put(tgt_info.tgt_mod);
> + return err;
> +}
> +
> static const struct bpf_link_ops bpf_tracing_link_lops = {
> .release = bpf_tracing_link_release,
> .dealloc = bpf_tracing_link_dealloc,
> .show_fdinfo = bpf_tracing_link_show_fdinfo,
> .fill_link_info = bpf_tracing_link_fill_link_info,
> + .update_prog = bpf_tracing_link_update_prog,
> };
>
SNIP
next prev parent reply other threads:[~2025-11-21 16:35 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-18 0:52 [RFC PATCH bpf-next 0/7] bpf: Implement BPF_LINK_UPDATE for tracing links Jordan Rife
2025-11-18 0:52 ` [RFC PATCH bpf-next 1/7] bpf: Set up update_prog scaffolding for bpf_tracing_link_lops Jordan Rife
2025-11-18 1:27 ` bot+bpf-ci
2025-11-20 19:23 ` Jordan Rife
2025-11-21 16:34 ` Jiri Olsa [this message]
2025-11-25 18:11 ` Jordan Rife
2025-11-18 0:52 ` [RFC PATCH bpf-next 2/7] bpf: Enable BPF_LINK_UPDATE for freplace links Jordan Rife
2025-11-18 0:52 ` [RFC PATCH bpf-next 3/7] bpf: Enable BPF_LINK_UPDATE for fentry/fexit/fmod_ret links Jordan Rife
2025-11-18 1:19 ` bot+bpf-ci
2025-11-20 19:23 ` Jordan Rife
2025-11-18 0:52 ` [RFC PATCH bpf-next 4/7] bpf, x86: Make program update work for trampoline ops Jordan Rife
2025-11-18 0:52 ` [RFC PATCH bpf-next 5/7] bpf, s390: " Jordan Rife
2025-11-18 0:52 ` [RFC PATCH bpf-next 6/7] bpf, arm64: " Jordan Rife
2025-11-18 0:52 ` [RFC PATCH bpf-next 7/7] selftests/bpf: Test BPF_LINK_UPDATE behavior for tracing links Jordan Rife
2025-11-22 1:43 ` [RFC PATCH bpf-next 0/7] bpf: Implement BPF_LINK_UPDATE " Alexei Starovoitov
2025-11-25 18:10 ` Jordan Rife
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=aSCUrtsBrfS2iTkB@krava \
--to=olsajiri@gmail.com \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=iii@linux.ibm.com \
--cc=jordan@jrife.io \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-s390@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=mingo@redhat.com \
--cc=puranjay@kernel.org \
--cc=x86@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 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.