(no subject)

[Siddharth_Cibi]

Subject: [PATCH 0/2] preserve rx_queue_index across XDP redirects

XDP programs executed after redirect through cpumap and devmap
currently lose ingress RX queue information because rx_queue_index
is not preserved across xdp_buff to xdp_frame conversion.

Preserve rx_queue_index in struct xdp_frame and restore it when
rebuilding xdp_rxq_info for redirected execution paths.

Add a selftest validating that ctx->rx_queue_index remains available
through xdp_metadata after redirect.

Testing:

* Built modified kernel objects
* Ran tools/testing/selftests/bpf/test_progs -t xdp_metadata -v
* Verified xdp_metadata passes
* Added explicit rx_queue_index assertion

Siddharth C (1):
  bpf: preserve rx_queue_index across XDP redirects

Siddharth_Cibi (1):
  selftests/bpf: validate rx_queue_index in xdp_metadata

 include/net/xdp.h                                     | 2 ++
 kernel/bpf/cpumap.c                                   | 2 +-
 kernel/bpf/devmap.c                                   | 5 ++++-
 net/core/xdp.c                                        | 1 +
 tools/testing/selftests/bpf/prog_tests/xdp_metadata.c | 3 ++-
 tools/testing/selftests/bpf/progs/xdp_metadata.c      | 2 +-
 tools/testing/selftests/bpf/xdp_metadata.h            | 1 +
 7 files changed, 12 insertions(+), 4 deletions(-)

-- 
2.53.0

[PATCH 1/2] bpf: preserve rx_queue_index across XDP redirects

[Siddharth_Cibi]

From: Siddharth C <siddharthcibi@icloud.com>

Store rx_queue_index in struct xdp_frame during xdp_buff to
xdp_frame conversion and restore it when rebuilding xdp_rxq_info
for cpumap and devmap execution paths.

This preserves ingress RX queue information for XDP programs
executed after redirect, allowing access to the original
rx_queue_index instead of losing queue context.

Also propagate rx_queue_index for zero-copy XDP frame conversion.

Signed-off-by: Siddharth_Cibi <siddharthcibi@icloud.com>
---
 include/net/xdp.h   | 2 ++
 kernel/bpf/cpumap.c | 2 +-
 kernel/bpf/devmap.c | 5 ++++-
 net/core/xdp.c      | 1 +
 4 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/include/net/xdp.h b/include/net/xdp.h
index aa742f413c35..90318b2b76dc 100644
--- a/include/net/xdp.h
+++ b/include/net/xdp.h
@@ -301,6 +301,7 @@ struct xdp_frame {
 	 */
 	enum xdp_mem_type mem_type:32;
 	struct net_device *dev_rx; /* used by cpumap */
+	u32 rx_queue_index;
 	u32 frame_sz;
 	u32 flags; /* supported values defined in xdp_buff_flags */
 };
@@ -441,6 +442,7 @@ struct xdp_frame *xdp_convert_buff_to_frame(struct xdp_buff *xdp)
 
 	/* rxq only valid until napi_schedule ends, convert to xdp_mem_type */
 	xdp_frame->mem_type = xdp->rxq->mem.type;
+	xdp_frame->rx_queue_index = xdp->rxq->queue_index;
 
 	return xdp_frame;
 }
diff --git a/kernel/bpf/cpumap.c b/kernel/bpf/cpumap.c
index 5e59ab896f05..8f2d7013620f 100644
--- a/kernel/bpf/cpumap.c
+++ b/kernel/bpf/cpumap.c
@@ -197,7 +197,7 @@ static int cpu_map_bpf_prog_run_xdp(struct bpf_cpu_map_entry *rcpu,
 
 		rxq.dev = xdpf->dev_rx;
 		rxq.mem.type = xdpf->mem_type;
-		/* TODO: report queue_index to xdp_rxq_info */
+		rxq.queue_index = xdpf->rx_queue_index;
 
 		xdp_convert_frame_to_buff(xdpf, &xdp);
 
diff --git a/kernel/bpf/devmap.c b/kernel/bpf/devmap.c
index dc7b859e8bbf..f419fa0e53e5 100644
--- a/kernel/bpf/devmap.c
+++ b/kernel/bpf/devmap.c
@@ -339,7 +339,7 @@ static int dev_map_bpf_prog_run(struct bpf_prog *xdp_prog,
 				struct net_device *rx_dev)
 {
 	struct xdp_txq_info txq = { .dev = tx_dev };
-	struct xdp_rxq_info rxq = { .dev = rx_dev };
+	struct xdp_rxq_info rxq = { };
 	struct xdp_buff xdp;
 	int i, nframes = 0;
 
@@ -349,6 +349,9 @@ static int dev_map_bpf_prog_run(struct bpf_prog *xdp_prog,
 		int err;
 
 		xdp_convert_frame_to_buff(xdpf, &xdp);
+		rxq.dev = rx_dev;
+		rxq.mem.type = xdpf->mem_type;
+		rxq.queue_index = xdpf->rx_queue_index;
 		xdp.txq = &txq;
 		xdp.rxq = &rxq;
 
diff --git a/net/core/xdp.c b/net/core/xdp.c
index 9890a30584ba..9691d8dfadf3 100644
--- a/net/core/xdp.c
+++ b/net/core/xdp.c
@@ -606,6 +606,7 @@ struct xdp_frame *xdp_convert_zc_to_xdp_frame(struct xdp_buff *xdp)
 	xdpf->metasize = metasize;
 	xdpf->frame_sz = PAGE_SIZE;
 	xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;
+	xdpf->rx_queue_index = xdp->rxq->queue_index;
 
 	xsk_buff_free(xdp);
 	return xdpf;
-- 
2.53.0

[PATCH 2/2] selftests/bpf: validate rx_queue_index in xdp_metadata

[Siddharth_Cibi]

Extend xdp_metadata selftest coverage to validate that
ctx->rx_queue_index is preserved and observable after XDP redirect
execution.

Capture rx_queue_index in metadata and assert that it matches the
expected queue during packet verification.

Signed-off-by: Siddharth_Cibi <siddharthcibi@icloud.com>
---
 tools/testing/selftests/bpf/prog_tests/xdp_metadata.c | 3 ++-
 tools/testing/selftests/bpf/progs/xdp_metadata.c      | 2 +-
 tools/testing/selftests/bpf/xdp_metadata.h            | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
index 5c31054ad4a4..f8cabbbe7bb7 100644
--- a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
+++ b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
@@ -309,7 +309,8 @@ static int verify_xsk_metadata(struct xsk *xsk, bool sent_from_af_xdp)
 
 	if (!ASSERT_NEQ(meta->rx_hash, 0, "rx_hash"))
 		return -1;
-
+	if (!ASSERT_EQ(meta->rx_queue_index, QUEUE_ID, "rx_queue_index"))
+        	return -1;
 	if (!sent_from_af_xdp) {
 		if (!ASSERT_NEQ(meta->rx_hash_type & XDP_RSS_TYPE_L4, 0, "rx_hash_type"))
 			return -1;
diff --git a/tools/testing/selftests/bpf/progs/xdp_metadata.c b/tools/testing/selftests/bpf/progs/xdp_metadata.c
index 09bb8a038d52..62ae83860d7f 100644
--- a/tools/testing/selftests/bpf/progs/xdp_metadata.c
+++ b/tools/testing/selftests/bpf/progs/xdp_metadata.c
@@ -98,7 +98,7 @@ int rx(struct xdp_md *ctx)
 	bpf_xdp_metadata_rx_hash(ctx, &meta->rx_hash, &meta->rx_hash_type);
 	bpf_xdp_metadata_rx_vlan_tag(ctx, &meta->rx_vlan_proto,
 				     &meta->rx_vlan_tci);
-
+	meta->rx_queue_index = ctx->rx_queue_index;
 	return bpf_redirect_map(&xsk, ctx->rx_queue_index, XDP_PASS);
 }
 
diff --git a/tools/testing/selftests/bpf/xdp_metadata.h b/tools/testing/selftests/bpf/xdp_metadata.h
index 87318ad1117a..1f0ae4c00091 100644
--- a/tools/testing/selftests/bpf/xdp_metadata.h
+++ b/tools/testing/selftests/bpf/xdp_metadata.h
@@ -49,4 +49,5 @@ struct xdp_meta {
 		__s32 rx_vlan_tag_err;
 	};
 	enum xdp_meta_field hint_valid;
+	__u32 rx_queue_index;
 };
-- 
2.53.0

Re: [PATCH 2/2] selftests/bpf: validate rx_queue_index in xdp_metadata

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [High] ABI / Struct Layout Mismatch on 32-bit platforms
- [Medium] Uninitialized Memory Leak in `xdp_hw_metadata` BPF Program
--

commit 601fd9ffcc49bcd779869ed0a9069b48be1a4a14
Author: Siddharth_Cibi <siddharthcibi@icloud.com>

selftests/bpf: validate rx_queue_index in xdp_metadata

This commit extends the xdp_metadata selftest to validate that
rx_queue_index is preserved after an XDP redirect. It captures the
queue index in the metadata and asserts it matches the expected queue ID.

> diff --git a/tools/testing/selftests/bpf/xdp_metadata.h b/tools/testing/selftests/bpf/xdp_metadata.h
> index 87318ad1117a1..1f0ae4c00091b 100644
> --- a/tools/testing/selftests/bpf/xdp_metadata.h
> +++ b/tools/testing/selftests/bpf/xdp_metadata.h
> @@ -49,4 +49,5 @@ struct xdp_meta {
>  		__s32 rx_vlan_tag_err;
>  	};
>  	enum xdp_meta_field hint_valid;
> +	__u32 rx_queue_index;
>  };

[Severity: High]
Will adding this 4-byte field without explicit padding cause an ABI layout
mismatch between 64-bit BPF programs and 32-bit user-space test environments?

On 64-bit architectures, the __u64 members force the struct alignment to
8 bytes, causing the compiler to implicitly pad the struct size to 40 bytes.
However, on 32-bit architectures like i386, __u64 only requires 4-byte
alignment, meaning the struct size remains exactly 36 bytes.

When verify_xsk_metadata() calculates the user-space pointer:

    meta = data - sizeof(struct xdp_meta);

Could this subtract 36 bytes instead of the 40 bytes reserved by the BPF
program on 32-bit platforms, shifting all metadata fields and causing the
user-space program to read corrupted values?

[Severity: Medium]
Does increasing the size of this struct expose uninitialized memory in
the xdp_hw_metadata BPF program?

Because struct xdp_meta is shared, xdp_hw_metadata.c now allocates more
headroom via bpf_xdp_adjust_meta().

Since xdp_hw_metadata.c wasn't updated to initialize rx_queue_index or
the new implicit padding, does this leave uninitialized packet headroom
memory exposed to user space via the AF_XDP socket?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619195759.41254-1-siddharthcibi@icloud.com?part=2

Re: [PATCH 1/2] bpf: preserve rx_queue_index across XDP redirects

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:

New issues:
- [High] Uninitialized `rx_queue_index` leak in the BPF `test_run` framework exposes kernel memory to BPF programs.

Pre-existing issues:
- [Critical] Incomplete metadata copy when manually duplicating `xdp_frame` in the DPAA driver causes uninitialized flags usage.
- [Critical] Converting a zero-copy XDP buffer with metadata into an `xdp_frame` causes an out-of-bounds write when an SKB is later built from it.
--

commit bc57980ef3c6d7e89349b8a948f430b656d7ecab
Author: Siddharth C <siddharthcibi@icloud.com>

bpf: preserve rx_queue_index across XDP redirects

Store rx_queue_index in struct xdp_frame during xdp_buff to xdp_frame
conversion and restore it when rebuilding xdp_rxq_info for cpumap and
devmap execution paths. This preserves ingress RX queue information for
XDP programs executed after redirect.

> diff --git a/include/net/xdp.h b/include/net/xdp.h
> index aa742f413c358..90318b2b76dcb 100644
> --- a/include/net/xdp.h
> +++ b/include/net/xdp.h
> @@ -301,6 +301,7 @@ struct xdp_frame {
>  	 */
>  	enum xdp_mem_type mem_type:32;
>  	struct net_device *dev_rx; /* used by cpumap */
> +	u32 rx_queue_index;

[Severity: High]
Does adding rx_queue_index here introduce a kernel memory leak in the BPF
test_run framework?

Looking at net/bpf/test_run.c, both xdp_test_run_init_page() and reset_ctx()
manually construct an xdp_frame using xdp_update_frame_from_buff().

Because xdp_update_frame_from_buff() does not copy rx_queue_index, and the
test_run code does not explicitly initialize it, frm->rx_queue_index appears
to retain uninitialized kernel memory from the page pool allocation.

If a test BPF program returns XDP_REDIRECT to a cpumap or devmap, will this
uninitialized rx_queue_index be exposed to the secondary BPF program via the
ctx->rx_queue_index context field, leaking 4 bytes of kernel memory per packet?

[Severity: Critical]
This is a pre-existing issue, but could manually duplicating the xdp_frame
cause uninitialized flags usage in the DPAA driver?

In drivers/net/ethernet/freescale/dpaa/dpaa_eth.c, dpaa_a050385_wa_xdpf()
manually duplicates an xdp_frame into a newly allocated buffer using
dev_alloc_pages(0).

It appears to leave several fields uninitialized, particularly flags. Since
the allocated page is not zeroed, new_xdpf->flags contains uninitialized
memory.

When xdp_return_frame() is later called on this frame, it checks for
XDP_FLAGS_HAS_FRAGS. If the uninitialized memory happens to have this flag
set, won't xdp_return_frame() read a bogus skb_shared_info from the end of
the page and attempt to free random memory addresses as fragments?

>  	u32 frame_sz;
>  	u32 flags; /* supported values defined in xdp_buff_flags */
>  };

[ ... ]

> diff --git a/net/core/xdp.c b/net/core/xdp.c
> index 9890a30584ba7..9691d8dfadf3c 100644
> --- a/net/core/xdp.c
> +++ b/net/core/xdp.c
> @@ -606,6 +606,7 @@ struct xdp_frame *xdp_convert_zc_to_xdp_frame(struct xdp_buff *xdp)
>  	xdpf->metasize = metasize;
>  	xdpf->frame_sz = PAGE_SIZE;
>  	xdpf->mem_type = MEM_TYPE_PAGE_ORDER0;
> +	xdpf->rx_queue_index = xdp->rxq->queue_index;

[Severity: Critical]
This isn't a bug introduced by this patch, but will setting headroom to 0
instead of metasize here cause an out-of-bounds write later?

Looking at xdp_convert_zc_to_xdp_frame(), it sets xdpf->headroom = 0 and
calculates the data offset using metasize.

Later, when __xdp_build_skb_from_frame() processes this frame, it calculates:

hard_start = xdpf->data - (sizeof(*xdpf) + xdpf->headroom)

which evaluates to page_virt + metasize. It then calls
build_skb_around(skb, hard_start, PAGE_SIZE).

This places the skb_shared_info structure at hard_start + PAGE_SIZE (minus
alignment). Because hard_start is offset by metasize, wouldn't the end of the
skb_shared_info overlap into the adjacent physical page by metasize bytes,
corrupting memory when the kernel zero-initializes this out-of-bounds area?

>  
>  	xsk_buff_free(xdp);
>  	return xdpf;

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260619195759.41254-1-siddharthcibi@icloud.com?part=1

Re: [PATCH 1/2] bpf: preserve rx_queue_index across XDP redirects

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 1429 bytes --]

> Store rx_queue_index in struct xdp_frame during xdp_buff to
> xdp_frame conversion and restore it when rebuilding xdp_rxq_info
> for cpumap and devmap execution paths.
> This preserves ingress RX queue information for XDP programs
> executed after redirect, allowing access to the original
> rx_queue_index instead of losing queue context.
> Also propagate rx_queue_index for zero-copy XDP frame conversion.
> Signed-off-by: Siddharth_Cibi <siddharthcibi@icloud.com>

This looks like a fix for the cpumap path, where the synthetic
xdp_rxq_info was previously built without a queue_index, leaving the
placeholder:

kernel/bpf/cpumap.c:cpu_map_bpf_prog_run_xdp() {
	rxq.dev = xdpf->dev_rx;
	rxq.mem.type = xdpf->mem_type;
	/* TODO: report queue_index to xdp_rxq_info */
	...
}

That synthetic xdp_rxq_info, with the missing queue_index and the TODO,
came in when cpu_map_bpf_prog_run_xdp() was added.  Should this carry:

  Fixes: 9216477449f3 ("bpf: cpumap: Add the possibility to attach an eBPF program to cpumap")

The devmap path (dev_map_bpf_prog_run) shares the same missing
queue_index, which was added in fbee97feed9b ("bpf: Add support to attach
bpf program to a devmap entry").


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27846609854

Re: [PATCH 2/2] selftests/bpf: validate rx_queue_index in xdp_metadata

[bot+bpf-ci]

[-- Attachment #1: Type: text/plain, Size: 3010 bytes --]

> Extend xdp_metadata selftest coverage to validate that
> ctx->rx_queue_index is preserved and observable after XDP redirect
> execution.
>
> Capture rx_queue_index in metadata and assert that it matches the
> expected queue during packet verification.
>
> Signed-off-by: Siddharth_Cibi <siddharthcibi@icloud.com>

The changelog says the test validates that ctx->rx_queue_index is
"preserved and observable after XDP redirect execution".

Looking at the program in progs/xdp_metadata.c, rx() reads
ctx->rx_queue_index and then redirects into an XSKMAP:

	meta->rx_queue_index = ctx->rx_queue_index;
	return bpf_redirect_map(&xsk, ctx->rx_queue_index, XDP_PASS);

The AF_XDP delivery path copies the frame and metadata straight into
the umem and does not re-run an XDP program after the redirect, so the
value stored in meta->rx_queue_index is the one read in the original
ingress context rather than a value restored on a later re-execution.

Does the assert in verify_xsk_metadata() actually exercise a
redirect-restore path, or does it pass purely from the value captured
in the ingress program?

This isn't a bug, but could the changelog describe which redirect path
the test exercises, since the AF_XDP (XSKMAP) path does not re-run an
XDP program after the redirect?

> diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
> index 5c31054ad4a4..f8cabbbe7bb7 100644
> --- a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
> +++ b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
> @@ -309,7 +309,8 @@ static int verify_xsk_metadata(struct xsk *xsk, bool sent_from_af_xdp)
>
>  	if (!ASSERT_NEQ(meta->rx_hash, 0, "rx_hash"))
>  		return -1;
> -
> +	if (!ASSERT_EQ(meta->rx_queue_index, QUEUE_ID, "rx_queue_index"))
> +        	return -1;

This isn't a bug, but the new return is indented with eight spaces
followed by a tab, while the other return -1; statements in
verify_xsk_metadata() use two tabs. Could it use tabs to match the
surrounding lines?

>  	if (!sent_from_af_xdp) {
>  		if (!ASSERT_NEQ(meta->rx_hash_type & XDP_RSS_TYPE_L4, 0, "rx_hash_type"))
>  			return -1;
> diff --git a/tools/testing/selftests/bpf/progs/xdp_metadata.c b/tools/testing/selftests/bpf/progs/xdp_metadata.c
> index 09bb8a038d52..62ae83860d7f 100644
> --- a/tools/testing/selftests/bpf/progs/xdp_metadata.c
> +++ b/tools/testing/selftests/bpf/progs/xdp_metadata.c
> @@ -98,7 +98,7 @@ int rx(struct xdp_md *ctx)
>  	bpf_xdp_metadata_rx_hash(ctx, &meta->rx_hash, &meta->rx_hash_type);
>  	bpf_xdp_metadata_rx_vlan_tag(ctx, &meta->rx_vlan_proto,
>  				     &meta->rx_vlan_tci);
> -
> +	meta->rx_queue_index = ctx->rx_queue_index;
>  	return bpf_redirect_map(&xsk, ctx->rx_queue_index, XDP_PASS);
>  }


---
AI reviewed your patch. Please fix the bug or email reply why it's not a bug.
See: https://github.com/kernel-patches/vmtest/blob/master/ci/claude/README.md

CI run summary: https://github.com/kernel-patches/bpf/actions/runs/27846609854

[PATCH 2/2] selftests/bpf: validate rx_queue_index in xdp_metadata

[Siddharth C]

From: Siddharth_Cibi <siddharthcibi@icloud.com>

Extend xdp_metadata selftest coverage to validate that
ctx->rx_queue_index is preserved and observable after XDP redirect
execution.

Capture rx_queue_index in metadata and assert that it matches the
expected queue during packet verification.

Signed-off-by: Siddharth_Cibi <siddharthcibi@icloud.com>
---
 tools/testing/selftests/bpf/prog_tests/xdp_metadata.c | 3 ++-
 tools/testing/selftests/bpf/progs/xdp_metadata.c      | 2 +-
 tools/testing/selftests/bpf/xdp_metadata.h            | 1 +
 3 files changed, 4 insertions(+), 2 deletions(-)

diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
index 5c31054ad4a4..f8cabbbe7bb7 100644
--- a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
+++ b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
@@ -309,7 +309,8 @@ static int verify_xsk_metadata(struct xsk *xsk, bool sent_from_af_xdp)
 
 	if (!ASSERT_NEQ(meta->rx_hash, 0, "rx_hash"))
 		return -1;
-
+	if (!ASSERT_EQ(meta->rx_queue_index, QUEUE_ID, "rx_queue_index"))
+        	return -1;
 	if (!sent_from_af_xdp) {
 		if (!ASSERT_NEQ(meta->rx_hash_type & XDP_RSS_TYPE_L4, 0, "rx_hash_type"))
 			return -1;
diff --git a/tools/testing/selftests/bpf/progs/xdp_metadata.c b/tools/testing/selftests/bpf/progs/xdp_metadata.c
index 09bb8a038d52..62ae83860d7f 100644
--- a/tools/testing/selftests/bpf/progs/xdp_metadata.c
+++ b/tools/testing/selftests/bpf/progs/xdp_metadata.c
@@ -98,7 +98,7 @@ int rx(struct xdp_md *ctx)
 	bpf_xdp_metadata_rx_hash(ctx, &meta->rx_hash, &meta->rx_hash_type);
 	bpf_xdp_metadata_rx_vlan_tag(ctx, &meta->rx_vlan_proto,
 				     &meta->rx_vlan_tci);
-
+	meta->rx_queue_index = ctx->rx_queue_index;
 	return bpf_redirect_map(&xsk, ctx->rx_queue_index, XDP_PASS);
 }
 
diff --git a/tools/testing/selftests/bpf/xdp_metadata.h b/tools/testing/selftests/bpf/xdp_metadata.h
index 87318ad1117a..1f0ae4c00091 100644
--- a/tools/testing/selftests/bpf/xdp_metadata.h
+++ b/tools/testing/selftests/bpf/xdp_metadata.h
@@ -49,4 +49,5 @@ struct xdp_meta {
 		__s32 rx_vlan_tag_err;
 	};
 	enum xdp_meta_field hint_valid;
+	__u32 rx_queue_index;
 };
-- 
2.53.0

Re: [PATCH 2/2] selftests/bpf: validate rx_queue_index in xdp_metadata

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Medium] Adding `rx_queue_index` changes `struct xdp_meta` size to 36 bytes, causing implicit padding to 40 bytes on 64-bit systems but not on 32-bit systems. This creates a BPF-to-userspace metadata offset mismatch on 32-bit hosts.
- [Low] The newly added assertion returns directly with incorrect space-based indentation.
--

commit 5d50c9ea90d4f7a83d1f9562df723456d7ed8e43
Author: Siddharth_Cibi <siddharthcibi@icloud.com>

selftests/bpf: validate rx_queue_index in xdp_metadata

This commit extends the xdp_metadata selftest to capture and validate
the rx_queue_index field. It adds the index to the xdp_meta structure and
asserts its value matches the expected queue during packet verification.

> diff --git a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
> --- a/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
> +++ b/tools/testing/selftests/bpf/prog_tests/xdp_metadata.c
> @@ -309,7 +309,8 @@ static int verify_xsk_metadata(struct xsk *xsk, bool sent_from_af_xdp)
>  
>  	if (!ASSERT_NEQ(meta->rx_hash, 0, "rx_hash"))
>  		return -1;
> -
> +	if (!ASSERT_EQ(meta->rx_queue_index, QUEUE_ID, "rx_queue_index"))
> +        	return -1;

[Severity: Low]
This isn't a bug, but does this return statement use spaces for indentation
instead of tabs?

[ ... ]

> diff --git a/tools/testing/selftests/bpf/xdp_metadata.h b/tools/testing/selftests/bpf/xdp_metadata.h
> --- a/tools/testing/selftests/bpf/xdp_metadata.h
> +++ b/tools/testing/selftests/bpf/xdp_metadata.h
> @@ -49,4 +49,5 @@ struct xdp_meta {
>  		__s32 rx_vlan_tag_err;
>  	};
>  	enum xdp_meta_field hint_valid;
> +	__u32 rx_queue_index;
>  };

[Severity: Medium]
Does adding rx_queue_index cause a structure size mismatch between the BPF
target and 32-bit hosts?

The xdp_meta struct contains __u64 fields, so on the BPF target and 64-bit
hosts, the 36-byte structure will be padded to 40 bytes to maintain 8-byte
alignment. In the BPF program, bpf_xdp_adjust_meta() will then allocate 40
bytes.

However, on 32-bit hosts where __u64 only requires 4-byte alignment, the
compiler will evaluate the structure size as 36 bytes. The userspace test
then reads the metadata pointer exactly 4 bytes after the start of the
BPF-populated metadata, leading to misaligned reads for all fields.

Should an explicit 4-byte padding field be added at the end of the struct,
or an explicit alignment attribute be used?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260620121321.45227-1-siddharthcibi@icloud.com?part=2