From: Maciej Fijalkowski <maciej.fijalkowski@intel.com>
To: Stanislav Fomichev <sdf@fomichev.me>
Cc: <bpf@vger.kernel.org>, <netdev@vger.kernel.org>, <ast@kernel.org>,
<daniel@iogearbox.net>, <andrii@kernel.org>,
<martin.lau@linux.dev>, <song@kernel.org>, <yhs@fb.com>,
<john.fastabend@gmail.com>, <kpsingh@kernel.org>,
<sdf@google.com>, <haoluo@google.com>, <jolsa@kernel.org>,
Julian Schindel <mail@arctic-alpaca.de>,
Magnus Karlsson <magnus.karlsson@gmail.com>
Subject: Re: [PATCH bpf 3/3] xsk: Try to make xdp_umem_reg extension a bit more future-proof
Date: Wed, 24 Jul 2024 17:21:36 +0200 [thread overview]
Message-ID: <ZqEcAKWCDp6lyaC9@boxer> (raw)
In-Reply-To: <20240713015253.121248-4-sdf@fomichev.me>
On Fri, Jul 12, 2024 at 06:52:53PM -0700, Stanislav Fomichev wrote:
> Add a couple of things:
> 1. Remove xdp_umem_reg_v2 since its sizeof is the same as xdp_umem_reg
So thing here is that adding __attribute__((packed)) on kernel side
wouldn't help because we wouldn't fix old uapi with this, correct? old
uapi would still yield 32 bytes for xdp_umem_reg without tx_metadata_len.
Just explaining here to myself.
> 2. Add BUILD_BUG_ON that checks that the size of xdp_umem_reg_v1 is less
> than xdp_umem_reg; presumably, when we get to v2, there is gonna
> be a similar line to enforce that sizeof(v2) > sizeof(v1)
> 3. Add BUILD_BUG_ON to make sure the last field plus its size matches
> the overall struct size. The intent is to demonstrate that we don't
> have any lingering padding.
This is good stuff but I wonder wouldn't it be more feasible to squash
this with 1/3 ? And have it backported. Regarding the patch logistics, you
did not provide fixes tag here for some reason, but still include the
patch routed via bpf tree.
>
> Reported-by: Julian Schindel <mail@arctic-alpaca.de>
> Cc: Magnus Karlsson <magnus.karlsson@gmail.com>
> Signed-off-by: Stanislav Fomichev <sdf@fomichev.me>
> ---
> net/xdp/xsk.c | 23 ++++++++++++-----------
> 1 file changed, 12 insertions(+), 11 deletions(-)
>
> diff --git a/net/xdp/xsk.c b/net/xdp/xsk.c
> index 7d1c0986f9bb..1d951d7e3797 100644
> --- a/net/xdp/xsk.c
> +++ b/net/xdp/xsk.c
> @@ -1331,14 +1331,6 @@ struct xdp_umem_reg_v1 {
> __u32 headroom;
> };
>
> -struct xdp_umem_reg_v2 {
> - __u64 addr; /* Start of packet data area */
> - __u64 len; /* Length of packet data area */
> - __u32 chunk_size;
> - __u32 headroom;
> - __u32 flags;
> -};
> -
> static int xsk_setsockopt(struct socket *sock, int level, int optname,
> sockptr_t optval, unsigned int optlen)
> {
> @@ -1382,10 +1374,19 @@ static int xsk_setsockopt(struct socket *sock, int level, int optname,
>
> if (optlen < sizeof(struct xdp_umem_reg_v1))
> return -EINVAL;
> - else if (optlen < sizeof(struct xdp_umem_reg_v2))
> - mr_size = sizeof(struct xdp_umem_reg_v1);
> else if (optlen < sizeof(mr))
> - mr_size = sizeof(struct xdp_umem_reg_v2);
> + mr_size = sizeof(struct xdp_umem_reg_v1);
> +
> + BUILD_BUG_ON(sizeof(struct xdp_umem_reg_v1) >= sizeof(struct xdp_umem_reg));
> +
> + /* Make sure the last field of the struct doesn't have
> + * uninitialized padding. All padding has to be explicit
> + * and has to be set to zero by the userspace to make
> + * struct xdp_umem_reg extensible in the future.
> + */
> + BUILD_BUG_ON(offsetof(struct xdp_umem_reg, tx_metadata_len) +
> + sizeof_field(struct xdp_umem_reg, tx_metadata_len) !=
> + sizeof(struct xdp_umem_reg));
>
> if (copy_from_sockptr(&mr, optval, mr_size))
> return -EFAULT;
> --
> 2.45.2
>
>
next prev parent reply other threads:[~2024-07-24 15:21 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-13 1:52 [PATCH bpf 0/3] xsk: require XDP_UMEM_TX_METADATA_LEN to actuate tx_metadata_len Stanislav Fomichev
2024-07-13 1:52 ` [PATCH bpf 1/3] " Stanislav Fomichev
2024-07-13 1:52 ` [PATCH bpf 2/3] selftests/bpf: Add XDP_UMEM_TX_METADATA_LEN to XSK TX metadata test Stanislav Fomichev
2024-07-13 1:52 ` [PATCH bpf 3/3] xsk: Try to make xdp_umem_reg extension a bit more future-proof Stanislav Fomichev
2024-07-24 15:21 ` Maciej Fijalkowski [this message]
2024-07-25 18:01 ` Stanislav Fomichev
2024-07-19 15:22 ` [PATCH bpf 0/3] xsk: require XDP_UMEM_TX_METADATA_LEN to actuate tx_metadata_len Daniel Borkmann
2024-07-19 15:29 ` Fijalkowski, Maciej
2024-07-19 15:40 ` Daniel Borkmann
2024-07-24 15:23 ` Maciej Fijalkowski
2024-07-25 10:06 ` Daniel Borkmann
2024-07-25 11:28 ` Maciej Fijalkowski
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=ZqEcAKWCDp6lyaC9@boxer \
--to=maciej.fijalkowski@intel.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=magnus.karlsson@gmail.com \
--cc=mail@arctic-alpaca.de \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=sdf@fomichev.me \
--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.