Re: [PATCH v4 bpf-next 09/11] bpf: Support ->fill_link_info for perf_event

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 





On 6/20/23 9:30 AM, Yafang Shao wrote:
By introducing support for ->fill_link_info to the perf_event link, users
gain the ability to inspect it using `bpftool link show`. While the current
approach involves accessing this information via `bpftool perf show`,
consolidating link information for all link types in one place offers
greater convenience. Additionally, this patch extends support to the
generic perf event, which is not currently accommodated by
`bpftool perf show`. While only the perf type and config are exposed to
userspace, other attributes such as sample_period and sample_freq are
ignored. It's important to note that if kptr_restrict is not permitted, the
probed address will not be exposed, maintaining security measures.

A new enum bpf_perf_event_type is introduced to help the user understand
which struct is relevant.

Signed-off-by: Yafang Shao <laoar.shao@xxxxxxxxx>
---
  include/uapi/linux/bpf.h       |  36 +++++++++++++
  kernel/bpf/syscall.c           | 115 +++++++++++++++++++++++++++++++++++++++++
  tools/include/uapi/linux/bpf.h |  36 +++++++++++++
  3 files changed, 187 insertions(+)

diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index 23691ea..56528dd 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -1056,6 +1056,16 @@ enum bpf_link_type {
  	MAX_BPF_LINK_TYPE,
  };
+enum bpf_perf_event_type {
+	BPF_PERF_EVENT_UNSPEC = 0,
+	BPF_PERF_EVENT_UPROBE = 1,
+	BPF_PERF_EVENT_KPROBE = 2,
+	BPF_PERF_EVENT_TRACEPOINT = 3,
+	BPF_PERF_EVENT_EVENT = 4,
+
+	MAX_BPF_PERF_EVENT_TYPE,
+};
+
  /* cgroup-bpf attach flags used in BPF_PROG_ATTACH command
   *
   * NONE(default): No further bpf programs allowed in the subtree.
@@ -6443,6 +6453,32 @@ struct bpf_link_info {
  			__u32 count;
  			__u32 flags;
  		} kprobe_multi;
+		struct {
+			__u32 type; /* enum bpf_perf_event_type */

Maybe add the following
			__u32 :32;
so later on this field can be reused if another u32 is needed in
the future?

+			union {
+				struct {
+					__aligned_u64 file_name; /* in/out */
+					__u32 name_len;
+					__u32 offset;/* offset from file_name */
+					__u32 flags;
+				} uprobe; /* BPF_PERF_EVENT_UPROBE */
+				struct {
+					__aligned_u64 func_name; /* in/out */
+					__u32 name_len;
+					__u32 offset;/* offset from func_name */
+					__u64 addr;
+					__u32 flags;
+				} kprobe; /* BPF_PERF_EVENT_KPROBE */
+				struct {
+					__aligned_u64 tp_name;   /* in/out */
+					__u32 name_len;
+				} tracepoint; /* BPF_PERF_EVENT_TRACEPOINT */
+				struct {
+					__u64 config;
+					__u32 type;
+				} event; /* BPF_PERF_EVENT_EVENT */
+			};
+		} perf_event;
  	};
  } __attribute__((aligned(8)));
[...]




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux