From: Yonghong Song <yonghong.song@linux.dev>
To: Eduard Zingerman <eddyz87@gmail.com>,
bpf@vger.kernel.org, ast@kernel.org
Cc: andrii@kernel.org, daniel@iogearbox.net, martin.lau@linux.dev,
kernel-team@fb.com, jose.marchesi@oracle.com
Subject: Re: [PATCH bpf-next 1/1] bpf: Mark virtual BPF context structures as preserve_static_offset
Date: Thu, 7 Dec 2023 19:36:04 -0800 [thread overview]
Message-ID: <6ea56936-1aca-4bcc-9a63-c61f8bcfabb9@linux.dev> (raw)
In-Reply-To: <20231208000531.19179-2-eddyz87@gmail.com>
On 12/7/23 4:05 PM, Eduard Zingerman wrote:
> Add __attribute__((preserve_static_offset)) for the following BPF
> related structures:
> - __sk_buff
> - bpf_cgroup_dev_ctx
> - bpf_perf_event_data
> - bpf_sk_lookup
> - bpf_sock
> - bpf_sock_addr
> - bpf_sock_ops
> - bpf_sockopt
> - bpf_sysctl
> - sk_msg_md
> - sk_reuseport_md
> - xdp_md
>
> Access to these structures is rewritten by BPF verifier.
> (See verifier.c:convert_ctx_access).
> The rewrite requires that offsets used in access to fields of these
> structures are constant values. __attribute__((preserve_static_offset))
> is a hint to clang that ensures that constant offsets are used.
> (See https://reviews.llvm.org/D133361 for details).
>
> Signed-off-by: Eduard Zingerman <eddyz87@gmail.com>
> ---
> include/uapi/linux/bpf.h | 28 ++++++++++++++---------
> include/uapi/linux/bpf_perf_event.h | 8 ++++++-
> tools/include/uapi/linux/bpf.h | 28 ++++++++++++++---------
> tools/include/uapi/linux/bpf_perf_event.h | 8 ++++++-
> 4 files changed, 48 insertions(+), 24 deletions(-)
>
> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> index e0545201b55f..75eee56ed732 100644
> --- a/include/uapi/linux/bpf.h
> +++ b/include/uapi/linux/bpf.h
> @@ -69,6 +69,12 @@ enum {
> /* BPF has 10 general purpose 64-bit registers and stack frame. */
> #define MAX_BPF_REG __MAX_BPF_REG
>
> +#if __has_attribute(preserve_static_offset) && defined(__bpf__)
> +#define __bpf_ctx __attribute__((preserve_static_offset))
> +#else
> +#define __bpf_ctx
> +#endif
> +
> struct bpf_insn {
> __u8 code; /* opcode */
> __u8 dst_reg:4; /* dest register */
> @@ -6190,7 +6196,7 @@ struct __sk_buff {
> __u8 tstamp_type;
> __u32 :24; /* Padding, future use. */
> __u64 hwtstamp;
> -};
> +} __bpf_ctx;
>
> struct bpf_tunnel_key {
> __u32 tunnel_id;
> @@ -6271,7 +6277,7 @@ struct bpf_sock {
> __u32 dst_ip6[4];
> __u32 state;
> __s32 rx_queue_mapping;
> -};
> +} __bpf_ctx;
>
> struct bpf_tcp_sock {
> __u32 snd_cwnd; /* Sending congestion window */
> @@ -6379,7 +6385,7 @@ struct xdp_md {
> __u32 rx_queue_index; /* rxq->queue_index */
>
> __u32 egress_ifindex; /* txq->dev->ifindex */
> -};
> +} __bpf_ctx;
>
> /* DEVMAP map-value layout
> *
> @@ -6429,7 +6435,7 @@ struct sk_msg_md {
> __u32 size; /* Total size of sk_msg */
>
> __bpf_md_ptr(struct bpf_sock *, sk); /* current socket */
> -};
> +} __bpf_ctx;
>
> struct sk_reuseport_md {
> /*
> @@ -6468,7 +6474,7 @@ struct sk_reuseport_md {
> */
> __bpf_md_ptr(struct bpf_sock *, sk);
> __bpf_md_ptr(struct bpf_sock *, migrating_sk);
> -};
> +} __bpf_ctx;
>
> #define BPF_TAG_SIZE 8
>
> @@ -6678,7 +6684,7 @@ struct bpf_sock_addr {
> * Stored in network byte order.
> */
> __bpf_md_ptr(struct bpf_sock *, sk);
> -};
> +} __bpf_ctx;
>
> /* User bpf_sock_ops struct to access socket values and specify request ops
> * and their replies.
> @@ -6761,7 +6767,7 @@ struct bpf_sock_ops {
> * been written yet.
> */
> __u64 skb_hwtstamp;
> -};
> +} __bpf_ctx;
>
> /* Definitions for bpf_sock_ops_cb_flags */
> enum {
> @@ -7034,7 +7040,7 @@ struct bpf_cgroup_dev_ctx {
> __u32 access_type;
> __u32 major;
> __u32 minor;
> -};
> +} __bpf_ctx;
>
> struct bpf_raw_tracepoint_args {
> __u64 args[0];
> @@ -7245,7 +7251,7 @@ struct bpf_sysctl {
> __u32 file_pos; /* Sysctl file position to read from, write to.
> * Allows 1,2,4-byte read an 4-byte write.
> */
> -};
> +} __bpf_ctx;
>
> struct bpf_sockopt {
> __bpf_md_ptr(struct bpf_sock *, sk);
> @@ -7256,7 +7262,7 @@ struct bpf_sockopt {
> __s32 optname;
> __s32 optlen;
> __s32 retval;
> -};
> +} __bpf_ctx;
>
> struct bpf_pidns_info {
> __u32 pid;
> @@ -7280,7 +7286,7 @@ struct bpf_sk_lookup {
> __u32 local_ip6[4]; /* Network byte order */
> __u32 local_port; /* Host byte order */
> __u32 ingress_ifindex; /* The arriving interface. Determined by inet_iif. */
> -};
> +} __bpf_ctx;
should we undef __bpf_ctx at the end of the file?
The same for below bpf_perf_event.h file.
>
> /*
> * struct btf_ptr is used for typed pointer representation; the
> diff --git a/include/uapi/linux/bpf_perf_event.h b/include/uapi/linux/bpf_perf_event.h
> index eb1b9d21250c..cf614ddf0381 100644
> --- a/include/uapi/linux/bpf_perf_event.h
> +++ b/include/uapi/linux/bpf_perf_event.h
> @@ -10,10 +10,16 @@
>
> #include <asm/bpf_perf_event.h>
>
> +#if __has_attribute(preserve_static_offset) && defined(__bpf__)
> +#define __bpf_ctx __attribute__((preserve_static_offset))
> +#else
> +#define __bpf_ctx
> +#endif
> +
> struct bpf_perf_event_data {
> bpf_user_pt_regs_t regs;
> __u64 sample_period;
> __u64 addr;
> -};
> +} __bpf_ctx;
>
> #endif /* _UAPI__LINUX_BPF_PERF_EVENT_H__ */
> diff --git a/tools/include/uapi/linux/bpf.h b/tools/include/uapi/linux/bpf.h
> index e0545201b55f..75eee56ed732 100644
> --- a/tools/include/uapi/linux/bpf.h
> +++ b/tools/include/uapi/linux/bpf.h
[...]
next prev parent reply other threads:[~2023-12-08 3:36 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-08 0:05 [PATCH bpf-next 0/1] use preserve_static_offset in bpf uapi headers Eduard Zingerman
2023-12-08 0:05 ` [PATCH bpf-next 1/1] bpf: Mark virtual BPF context structures as preserve_static_offset Eduard Zingerman
2023-12-08 3:36 ` Yonghong Song [this message]
2023-12-08 14:23 ` Eduard Zingerman
2023-12-08 2:28 ` [PATCH bpf-next 0/1] use preserve_static_offset in bpf uapi headers Yonghong Song
2023-12-08 14:34 ` Eduard Zingerman
2023-12-08 17:19 ` Yonghong Song
2023-12-08 20:54 ` Eduard Zingerman
2023-12-08 17:30 ` Yonghong Song
2023-12-08 17:46 ` Alexei Starovoitov
2023-12-08 20:35 ` Eduard Zingerman
2023-12-08 12:27 ` Alan Maguire
2023-12-08 14:21 ` Eduard Zingerman
2023-12-08 15:35 ` Alan Maguire
2023-12-08 15:39 ` Eduard Zingerman
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=6ea56936-1aca-4bcc-9a63-c61f8bcfabb9@linux.dev \
--to=yonghong.song@linux.dev \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=jose.marchesi@oracle.com \
--cc=kernel-team@fb.com \
--cc=martin.lau@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 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.