All of lore.kernel.org
 help / color / mirror / Atom feed
From: Alexei Starovoitov <alexei.starovoitov@gmail.com>
To: Yafang Shao <laoar.shao@gmail.com>
Cc: ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
	andrii@kernel.org, martin.lau@linux.dev, song@kernel.org,
	yhs@fb.com, kpsingh@kernel.org, sdf@google.com,
	haoluo@google.com, jolsa@kernel.org, quentin@isovalent.com,
	bpf@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next 7/8] bpf: Support ->fill_link_info for perf_event
Date: Tue, 30 May 2023 17:37:13 -0700	[thread overview]
Message-ID: <20230531003713.ml3gb76q4zurue3a@MacBook-Pro-8.local> (raw)
In-Reply-To: <20230528142027.5585-8-laoar.shao@gmail.com>

On Sun, May 28, 2023 at 02:20:26PM +0000, Yafang Shao wrote:
> By adding support for ->fill_link_info to the perf_event link, users will
> be able to inspect it using `bpftool link show`. While users can currently
> access this information via `bpftool perf show`, consolidating the link
> information for all link types in one place would be more convenient.
> 
> Signed-off-by: Yafang Shao <laoar.shao@gmail.com>
> ---
>  include/uapi/linux/bpf.h       |  6 ++++++
>  kernel/bpf/syscall.c           | 46 ++++++++++++++++++++++++++++++++++++++++++
>  tools/include/uapi/linux/bpf.h |  6 ++++++
>  3 files changed, 58 insertions(+)
> 
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index 6be9b1d..1f2be1d 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -6438,6 +6438,12 @@ struct bpf_link_info {
>  			__aligned_u64 addrs;
>  			__u32 count;
>  		} kprobe_multi;
> +		struct {
> +			__aligned_u64 name;
> +			__aligned_u64 addr;

__aligned_u64 ? what is the reason?

> +			__u32 name_len;
> +			__u32 offset;
> +		} perf_event;
>  	};
>  } __attribute__((aligned(8)));
>  
> diff --git a/kernel/bpf/syscall.c b/kernel/bpf/syscall.c
> index 33a72ec..b12707e 100644
> --- a/kernel/bpf/syscall.c
> +++ b/kernel/bpf/syscall.c
> @@ -3329,10 +3329,56 @@ static void bpf_perf_link_show_fdinfo(const struct bpf_link *link,
>  	seq_printf(seq, "offset:\t%llu\n", probe_offset);
>  }
>  
> +static int bpf_perf_link_fill_link_info(const struct bpf_link *link,
> +					struct bpf_link_info *info)
> +{
> +	struct bpf_perf_link *perf_link = container_of(link, struct bpf_perf_link, link);
> +	char __user *ubuf = u64_to_user_ptr(info->perf_event.name);
> +	u32 ulen = info->perf_event.name_len;
> +	const struct perf_event *event;
> +	u64 probe_offset, probe_addr;
> +	u32 prog_id, fd_type;
> +	const char *buf;
> +	size_t len;
> +	int err;
> +
> +	if (!ulen ^ !ubuf)
> +		return -EINVAL;
> +	if (!ubuf)
> +		return 0;
> +
> +	event = perf_get_event(perf_link->perf_file);
> +	if (IS_ERR(event))
> +		return PTR_ERR(event);
> +
> +	err = bpf_get_perf_event_info(event, &prog_id, &fd_type,
> +				      &buf, &probe_offset,
> +				      &probe_addr);
> +	if (err)
> +		return err;
> +
> +	len = strlen(buf);
> +	info->perf_event.name_len = len + 1;

this use of name_len contradicts with patch 8.
Is it 'in' or 'out' field?

> +	if (buf) {
> +		err = bpf_copy_to_user(ubuf, buf, ulen, len);
> +		if (err)
> +			return err;
> +	} else {
> +		char zero = '\0';
> +
> +		if (put_user(zero, ubuf))
> +			return -EFAULT;
> +	}
> +	info->perf_event.addr = probe_addr;
> +	info->perf_event.offset = probe_offset;
> +	return 0;
> +}
> +
>  static const struct bpf_link_ops bpf_perf_link_lops = {
>  	.release = bpf_perf_link_release,
>  	.dealloc = bpf_perf_link_dealloc,
>  	.show_fdinfo = bpf_perf_link_show_fdinfo,
> +	.fill_link_info = bpf_perf_link_fill_link_info,
>  };
>  
>  static int bpf_perf_link_attach(const union bpf_attr *attr, struct bpf_prog *prog)
> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index 6be9b1d..1f2be1d 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
> @@ -6438,6 +6438,12 @@ struct bpf_link_info {
>  			__aligned_u64 addrs;
>  			__u32 count;
>  		} kprobe_multi;
> +		struct {
> +			__aligned_u64 name;
> +			__aligned_u64 addr;
> +			__u32 name_len;
> +			__u32 offset;
> +		} perf_event;
>  	};
>  } __attribute__((aligned(8)));
>  
> -- 
> 1.8.3.1
> 

  reply	other threads:[~2023-05-31  0:39 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-05-28 14:20 [RFC PATCH bpf-next 0/8] bpf: Support ->show_fdinfo and ->fill_link_info for kprobe prog Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 1/8] bpf: Support ->show_fdinfo for kprobe_multi Yafang Shao
2023-05-29 12:06   ` Jiri Olsa
2023-05-30  1:39     ` Yafang Shao
2023-05-31  0:28       ` Alexei Starovoitov
2023-05-31  3:14         ` Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 2/8] bpf: Support ->fill_link_info " Yafang Shao
2023-05-29  2:44   ` kernel test robot
2023-05-30  1:42     ` Yafang Shao
2023-05-29 12:49   ` Jiri Olsa
2023-05-30  1:41     ` Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 3/8] bpftool: Show probed function in kprobe_multi link info Yafang Shao
2023-05-30 11:15   ` Quentin Monnet
2023-05-31  3:16     ` Yafang Shao
2023-05-31  0:31   ` Alexei Starovoitov
2023-05-31  3:17     ` Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 4/8] bpf: Always expose the probed address Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 5/8] bpf: Support ->show_fdinfo for perf_event Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 6/8] bpf: Add a common helper bpf_copy_to_user() Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 7/8] bpf: Support ->fill_link_info for perf_event Yafang Shao
2023-05-31  0:37   ` Alexei Starovoitov [this message]
2023-05-31  3:24     ` Yafang Shao
2023-05-28 14:20 ` [RFC PATCH bpf-next 8/8] bpftool: Show probed function in perf_event link info Yafang Shao

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=20230531003713.ml3gb76q4zurue3a@MacBook-Pro-8.local \
    --to=alexei.starovoitov@gmail.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kpsingh@kernel.org \
    --cc=laoar.shao@gmail.com \
    --cc=martin.lau@linux.dev \
    --cc=quentin@isovalent.com \
    --cc=sdf@google.com \
    --cc=song@kernel.org \
    --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.