From: "Arnd Bergmann" <arnd@arndb.de>
To: "Yonghong Song" <yonghong.song@linux.dev>,
"Arnd Bergmann" <arnd@kernel.org>,
"Alexei Starovoitov" <ast@kernel.org>,
"Daniel Borkmann" <daniel@iogearbox.net>,
"Andrii Nakryiko" <andrii@kernel.org>,
"Eduard Zingerman" <eddyz87@gmail.com>,
"Kumar Kartikeya Dwivedi" <memxor@gmail.com>,
"Leon Hwang" <leon.hwang@linux.dev>
Cc: "Martin KaFai Lau" <martin.lau@linux.dev>,
"Song Liu" <song@kernel.org>, "Jiri Olsa" <jolsa@kernel.org>,
"KP Singh" <kpsingh@kernel.org>,
bpf@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] bpf: avoid padding in struct bpf_common_attr
Date: Wed, 20 May 2026 08:36:51 +0200 [thread overview]
Message-ID: <8e9cdb17-83c6-4287-91eb-dd6d3a457f28@app.fastmail.com> (raw)
In-Reply-To: <9eecfab7-afac-4144-b544-ac715b07980e@linux.dev>
On Wed, May 20, 2026, at 00:17, Yonghong Song wrote:
> On 5/19/26 1:38 PM, Arnd Bergmann wrote:
>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
>> index cc4c0b62cdfa..0f0ec00cae4a 100644
>> --- a/include/uapi/linux/bpf.h
>> +++ b/include/uapi/linux/bpf.h
>> @@ -1507,6 +1507,7 @@ struct bpf_common_attr {
>> __u32 log_size;
>> __u32 log_level;
>> __u32 log_true_size;
>> + __u32 __pad;
>
> Let us make it as
> __u32 :32;
> ?
> This can avoid people to use the '__pad' name.
Sure. Do you want me to resend, are are you going to change
it yourself?
> IIUC, typically uapi struct won't have implicit padding.
Correct. I have a patch set that I'm testing to add the
Warning to the kernel build process to find these
automatically, but I first need to take care of all the
existing instances and only report newly added ones at
the moment.
FWIW, see below for what I currently have in my private
tree for linux/bpf.h. Most of these ones are architecture
independent, so I just do the same '__u32 :32' that you
suggested above. For bpf_cgroup_storage_key and
bpf_attr::link_create::{tracing,tcx,expected_revision,cgroup}
there is an additional problem sinc ethe 64-bit fields
use __u64 instead of __aligned_u64.
This makes the structure layout incompatible between
i386 and x86_64. In the version below I use a
__uapi_arch_pad32 macro to have architecture specific
padding that keeps the existing behavior, but this
technically also requires adding a compat syscall
on x86 (but no other compat architectures) to convert
between the two layouts.
Using __aligned_u64 consistently here would have avoided
this problem, but changing it later is not an ABI
change that would affect every architecture with
unaligned __u64 (arc, csky, m68k, microblaze, nios2,
openrisc, sh and i386).
Arnd
diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
index aec171ccb6ef..0f0ec00cae4a 100644
--- a/include/uapi/linux/bpf.h
+++ b/include/uapi/linux/bpf.h
@@ -111,7 +111,8 @@ struct bpf_lpm_trie_key_u8 {
struct bpf_cgroup_storage_key {
__u64 cgroup_inode_id; /* cgroup inode id */
__u32 attach_type; /* program attach type (enum bpf_attach_type) */
-};
+ __uapi_arch_pad32;
+} __uapi_arch_align;
enum bpf_cgroup_iter_order {
BPF_CGROUP_ITER_ORDER_UNSPEC = 0,
@@ -1562,10 +1564,12 @@ union bpf_attr {
__aligned_u64 excl_prog_hash;
/* Size of the passed excl_prog_hash. */
__u32 excl_prog_hash_size;
+ __u32 :32;
};
struct { /* anonymous struct used by BPF_MAP_*_ELEM and BPF_MAP_FREEZE commands */
__u32 map_fd;
+ __u32 :32;
__aligned_u64 key;
union {
__aligned_u64 value;
@@ -1668,6 +1672,7 @@ union bpf_attr {
* if BPF_F_PATH_FD flag is not set, AT_FDCWD is assumed.
*/
__s32 path_fd;
+ __u32 :32;
};
struct { /* anonymous struct used by BPF_PROG_ATTACH/DETACH commands */
@@ -1708,6 +1713,7 @@ union bpf_attr {
__u32 flags;
__u32 cpu;
__u32 batch_size;
+ __u32 :32;
} test;
struct { /* anonymous struct used by BPF_*_GET_*_ID */
@@ -1809,6 +1815,7 @@ union bpf_attr {
struct {
__aligned_u64 iter_info; /* extra bpf_iter_link_info */
__u32 iter_info_len; /* iter_info length */
+ __u32 :32;
};
struct {
/* black box user-provided value passed through
@@ -1827,12 +1834,13 @@ union bpf_attr {
struct {
/* this is overlaid with the target_btf_id above. */
__u32 target_btf_id;
+ __uapi_arch_pad32;
/* black box user-provided value passed through
* to BPF program at the execution time and
* accessible through bpf_get_attach_cookie() BPF helper
*/
__u64 cookie;
- } tracing;
+ } __uapi_arch_align tracing;
struct {
__u32 pf;
__u32 hooknum;
@@ -1844,8 +1852,9 @@ union bpf_attr {
__u32 relative_fd;
__u32 relative_id;
};
+ __uapi_arch_pad32;
__u64 expected_revision;
- } tcx;
+ } __uapi_arch_align tcx;
struct {
__aligned_u64 path;
__aligned_u64 offsets;
@@ -1854,12 +1863,14 @@ union bpf_attr {
__u32 cnt;
__u32 flags;
__u32 pid;
+ __u32 :32;
} uprobe_multi;
struct {
union {
__u32 relative_fd;
__u32 relative_id;
};
+ __uapi_arch_pad32;
__u64 expected_revision;
} netkit;
struct {
@@ -1867,6 +1878,7 @@ union bpf_attr {
__u32 relative_fd;
__u32 relative_id;
};
+ __uapi_arch_pad32;
__u64 expected_revision;
} cgroup;
};
@@ -1922,6 +1934,7 @@ union bpf_attr {
__u32 stream_buf_len;
__u32 stream_id;
__u32 prog_fd;
+ __u32 :32;
} prog_stream_read;
struct {
@@ -6648,6 +6661,7 @@ struct sk_reuseport_md {
__u32 ip_protocol; /* IP protocol. e.g. IPPROTO_TCP, IPPROTO_UDP */
__u32 bind_inany; /* Is sock bound to an INANY address? */
__u32 hash; /* A hash of the packet 4 tuples */
+ __u32 :32;
/* When reuse->migrating_sk is NULL, it is selecting a sk for the
* new incoming connection request (e.g. selecting a listen sk for
* the received SYN in the TCP case). reuse->sk is one of the sk
@@ -6706,6 +6720,7 @@ struct bpf_prog_info {
__u32 verified_insns;
__u32 attach_btf_obj_id;
__u32 attach_btf_id;
+ __u32 :32; /* alignment pad */
} __attribute__((aligned(8)));
struct bpf_map_info {
@@ -6727,6 +6742,7 @@ struct bpf_map_info {
__u64 map_extra;
__aligned_u64 hash;
__u32 hash_size;
+ __u32 :32; /* alignment pad */
} __attribute__((aligned(8)));
struct bpf_btf_info {
@@ -6742,6 +6758,7 @@ struct bpf_link_info {
__u32 type;
__u32 id;
__u32 prog_id;
+ __u32 :32; /* pad to alignof(__aligned_u64) */
union {
struct {
__aligned_u64 tp_name; /* in/out: tp_name buffer ptr */
@@ -6759,6 +6776,7 @@ struct bpf_link_info {
struct {
__u64 cgroup_id;
__u32 attach_type;
+ __uapi_arch_pad32;
} cgroup;
struct {
__aligned_u64 target_name; /* in/out: target_name buffer ptr */
@@ -6777,11 +6795,16 @@ struct bpf_link_info {
struct {
__u64 cgroup_id;
__u32 order;
+ __uapi_arch_pad32;
} cgroup;
struct {
__u32 tid;
__u32 pid;
} task;
+ struct {
+ __u64 :64;
+ __u64 :64;
+ };
};
} iter;
struct {
@@ -6896,6 +6919,7 @@ struct bpf_sock_addr {
__u32 msg_src_ip6[4]; /* Allows 1,2,4,8-byte read and 4,8-byte write.
* Stored in network byte order.
*/
+ __u32 :32; /* pad to alignof(u64) */
__bpf_md_ptr(struct bpf_sock *, sk);
};
@@ -7555,6 +7579,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. */
+ __u32 :32;
};
/*
next prev parent reply other threads:[~2026-05-20 6:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-05-19 20:38 Arnd Bergmann
2026-05-19 20:52 ` Song Liu
2026-05-20 7:51 ` Geert Uytterhoeven
2026-05-19 21:17 ` bot+bpf-ci
2026-05-19 22:17 ` Yonghong Song
2026-05-20 6:36 ` Arnd Bergmann [this message]
2026-05-20 14:03 ` Alexei Starovoitov
2026-05-20 14:22 ` Geert Uytterhoeven
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=8e9cdb17-83c6-4287-91eb-dd6d3a457f28@app.fastmail.com \
--to=arnd@arndb.de \
--cc=andrii@kernel.org \
--cc=arnd@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=eddyz87@gmail.com \
--cc=jolsa@kernel.org \
--cc=kpsingh@kernel.org \
--cc=leon.hwang@linux.dev \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=song@kernel.org \
--cc=yonghong.song@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®