All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <eric.dumazet@gmail.com>
To: Joe Burton <jevburton.kernel@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>,
	Martin KaFai Lau <kafai@fb.com>
Cc: Song Liu <songliubraving@fb.com>, Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>, Petar Penkov <ppenkov@google.com>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	netdev@vger.kernel.org, bpf@vger.kernel.org,
	Joe Burton <jevburton@google.com>
Subject: Re: [RFC PATCH v2 04/13] bpf: Define a few bpf_link_ops for BPF_TRACE_MAP
Date: Wed, 29 Sep 2021 17:26:01 -0700	[thread overview]
Message-ID: <1c148ba0-0b74-2d48-c94b-3e7ea42e8238@gmail.com> (raw)
In-Reply-To: <20210929235910.1765396-5-jevburton.kernel@gmail.com>



On 9/29/21 4:59 PM, Joe Burton wrote:
> From: Joe Burton <jevburton@google.com>
> 
> Define release, dealloc, and update_prog for the new tracing programs.
> Updates are protected by a single global mutex.
> 
> Signed-off-by: Joe Burton <jevburton@google.com>
> ---
>  kernel/bpf/map_trace.c | 71 ++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
> 
> diff --git a/kernel/bpf/map_trace.c b/kernel/bpf/map_trace.c
> index 7776b8ccfe88..35906d59ba3c 100644
> --- a/kernel/bpf/map_trace.c
> +++ b/kernel/bpf/map_trace.c
> @@ -14,6 +14,14 @@ struct bpf_map_trace_target_info {
>  static struct list_head targets = LIST_HEAD_INIT(targets);
>  static DEFINE_MUTEX(targets_mutex);
>  
> +struct bpf_map_trace_link {
> +	struct bpf_link link;
> +	struct bpf_map *map;
> +	struct bpf_map_trace_target_info *tinfo;
> +};
> +
> +static DEFINE_MUTEX(link_mutex);
> +
>  int bpf_map_trace_reg_target(const struct bpf_map_trace_reg *reg_info)
>  {
>  	struct bpf_map_trace_target_info *tinfo;
> @@ -77,3 +85,66 @@ int bpf_map_initialize_trace_progs(struct bpf_map *map)
>  	return 0;
>  }
>  
> +static void bpf_map_trace_link_release(struct bpf_link *link)
> +{
> +	struct bpf_map_trace_link *map_trace_link =
> +			container_of(link, struct bpf_map_trace_link, link);
> +	enum bpf_map_trace_type trace_type =
> +			map_trace_link->tinfo->reg_info->trace_type;
> +	struct bpf_map_trace_prog *cur_prog;
> +	struct bpf_map_trace_progs *progs;
> +
> +	progs = map_trace_link->map->trace_progs;
> +	mutex_lock(&progs->mutex);
> +	list_for_each_entry(cur_prog, &progs->progs[trace_type].list, list) {

You might consider using list_for_each_entry_safe(), or ...

> +		if (cur_prog->prog == link->prog) {
> +			progs->length[trace_type] -= 1;
> +			list_del_rcu(&cur_prog->list);
> +			kfree_rcu(cur_prog, rcu);

or add a break; if you do not expect to find multiple entries.

> +		}
> +	}
> +	mutex_unlock(&progs->mutex);
> +	bpf_map_put_with_uref(map_trace_link->map);
> +}
> +
> +static void bpf_map_trace_link_dealloc(struct bpf_link *link)
> +{
> +	struct bpf_map_trace_link *map_trace_link =
> +			container_of(link, struct bpf_map_trace_link, link);
> +
> +	kfree(map_trace_link);
> +}
> +
> +static int bpf_map_trace_link_replace(struct bpf_link *link,
> +				      struct bpf_prog *new_prog,
> +				      struct bpf_prog *old_prog)
> +{
> +	int ret = 0;
> +
> +	mutex_lock(&link_mutex);
> +	if (old_prog && link->prog != old_prog) {
> +		ret = -EPERM;
> +		goto out_unlock;
> +	}
> +
> +	if (link->prog->type != new_prog->type ||
> +	    link->prog->expected_attach_type != new_prog->expected_attach_type ||
> +	    link->prog->aux->attach_btf_id != new_prog->aux->attach_btf_id) {
> +		ret = -EINVAL;
> +		goto out_unlock;
> +	}
> +
> +	old_prog = xchg(&link->prog, new_prog);
> +	bpf_prog_put(old_prog);
> +
> +out_unlock:
> +	mutex_unlock(&link_mutex);
> +	return ret;
> +}
> +
> +static const struct bpf_link_ops bpf_map_trace_link_ops = {
> +	.release = bpf_map_trace_link_release,
> +	.dealloc = bpf_map_trace_link_dealloc,
> +	.update_prog = bpf_map_trace_link_replace,
> +};
> +
> 

  reply	other threads:[~2021-09-30  0:26 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-29 23:58 [RFC PATCH v2 00/13] Introduce BPF map tracing capability Joe Burton
2021-09-29 23:58 ` [RFC PATCH v2 01/13] bpf: Add machinery to register map tracing hooks Joe Burton
2021-09-29 23:58 ` [RFC PATCH v2 02/13] bpf: Allow loading BPF_TRACE_MAP programs Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 03/13] bpf: Add list of tracing programs to struct bpf_map Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 04/13] bpf: Define a few bpf_link_ops for BPF_TRACE_MAP Joe Burton
2021-09-30  0:26   ` Eric Dumazet [this message]
2021-09-30  1:09     ` Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 05/13] bpf: Enable creation of BPF_LINK_TYPE_MAP_TRACE Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 06/13] bpf: Add APIs to invoke tracing programs Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 07/13] bpf: Register BPF_MAP_TRACE_{UPDATE,DELETE}_ELEM hooks Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 08/13] libbpf: Support BPF_TRACE_MAP Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 09/13] bpf: Add infinite loop check on map tracers Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 10/13] Add bpf_map_trace_{update,delete}_elem() helper functions Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 11/13] bpf: verifier inserts map tracing helper call Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 12/13] bpf: Add selftests for map tracing Joe Burton
2021-09-29 23:59 ` [RFC PATCH v2 13/13] bpf: Add real world example " Joe Burton
2021-10-05  5:13 ` [RFC PATCH v2 00/13] Introduce BPF map tracing capability Alexei Starovoitov
2021-10-05 21:47   ` Joe Burton
2021-10-06 16:41     ` Alexei Starovoitov
2021-10-06 21:05       ` Joe Burton
2021-10-18 23:15         ` Alexei Starovoitov

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=1c148ba0-0b74-2d48-c94b-3e7ea42e8238@gmail.com \
    --to=eric.dumazet@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=jevburton.kernel@gmail.com \
    --cc=jevburton@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=netdev@vger.kernel.org \
    --cc=ppenkov@google.com \
    --cc=sdf@google.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@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.