[PATCH net v2 0/4] net: mvpp2: fix XDP RX buffer handling

[PATCH net v2 0/4] net: mvpp2: fix XDP RX buffer handling

[Til Kaiser]

This is v2 of the earlier XDP_PASS fix. The XDP_PASS change is retained,
and the series now also fixes related RX/XDP buffer handling issues found
during review.

---
v1: https://lore.kernel.org/all/20260524122334.1730451-1-mail@tk154.de/

Changes in v2:
- Fixed RX DMA sync range to account for RX headroom.
- Limited XDP frame size to the actual RX buffer size.
- Fixed refill error paths so retired buffers are not returned to BM.

Til Kaiser (4):
  net: mvpp2: sync RX data at the hardware packet offset
  net: mvpp2: limit XDP frame size to the RX buffer
  net: mvpp2: do not return retired RX buffers to BM
  net: mvpp2: build skb from XDP-adjusted data on XDP_PASS

 .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 38 ++++++++++++-------
 1 file changed, 25 insertions(+), 13 deletions(-)

-- 
2.54.0

[PATCH net v2 1/4] net: mvpp2: sync RX data at the hardware packet offset

[Til Kaiser]

mvpp2 programs the RX queue packet offset, so hardware writes received
data at dma_addr + MVPP2_SKB_HEADROOM. The current CPU sync starts at
dma_addr and only covers rx_bytes + MVPP2_MH_SIZE bytes, which syncs the
unused headroom and misses the same number of bytes at the packet tail.

On non-coherent DMA systems this can leave the CPU reading stale cache
contents for the end of the received frame.

Use dma_sync_single_range_for_cpu() with MVPP2_SKB_HEADROOM as the range
offset so the sync covers the Marvell header and packet data actually
written by hardware.

Fixes: e1921168bbd4 ("mvpp2: sync only the received frame")
Signed-off-by: Til Kaiser <mail@tk154.de>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 7 ++++---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index f442b874bb59..92a701f4fe3f 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3946,9 +3946,10 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 			dma_dir = DMA_FROM_DEVICE;
 		}
 
-		dma_sync_single_for_cpu(dev->dev.parent, dma_addr,
-					rx_bytes + MVPP2_MH_SIZE,
-					dma_dir);
+		dma_sync_single_range_for_cpu(dev->dev.parent, dma_addr,
+					      MVPP2_SKB_HEADROOM,
+					      rx_bytes + MVPP2_MH_SIZE,
+					      dma_dir);
 
 		/* Buffer header not supported */
 		if (rx_status & MVPP2_RXD_BUF_HDR)
-- 
2.54.0

[PATCH net v2 2/4] net: mvpp2: limit XDP frame size to the RX buffer

[Til Kaiser]

mvpp2 has short and long BM pools, and short pool buffers can be smaller
than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with
PAGE_SIZE as frame size.

XDP helpers use frame_sz to validate tail growth and to derive the hard
end of the data area. Advertising PAGE_SIZE for short buffers can let
bpf_xdp_adjust_tail() grow a packet past the real allocation, corrupting
memory or later tripping skb tailroom checks.

Initialize the XDP buffer with bm_pool->frag_size so XDP tailroom matches
the actual buffer backing the packet.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Signed-off-by: Til Kaiser <mail@tk154.de>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 92a701f4fe3f..3372ed27cc8d 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3979,7 +3979,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 			else
 				xdp_rxq = &rxq->xdp_rxq_long;
 
-			xdp_init_buff(&xdp, PAGE_SIZE, xdp_rxq);
+			xdp_init_buff(&xdp, bm_pool->frag_size, xdp_rxq);
 			xdp_prepare_buff(&xdp, data,
 					 MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM,
 					 rx_bytes, true);
-- 
2.54.0

[PATCH net v2 3/4] net: mvpp2: do not return retired RX buffers to BM

[Til Kaiser]

The RX refill failure path jumps to err_drop_frame, which returns the
descriptor buffer to the hardware BM pool. That is only valid while the
driver still owns the buffer.

After a non-PASS XDP verdict, mvpp2_run_xdp() may already have recycled,
redirected, or queued the page for XDP_TX. After build_skb(), freeing the
skb on refill failure also retires the data buffer. Returning either of
those buffers to BM lets hardware DMA into memory that is no longer owned
by the RX ring.

Split the error handling so buffers are returned to BM only while still
owned by the driver. Once XDP or an skb owns the buffer, only account the
RX error. Mark page-pool skbs for recycle before they can be freed on the
refill failure path, and unmap non-page-pool buffers before freeing them.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Fixes: d6526926de73 ("net: mvpp2: fix memory leak in mvpp2_rx")
Signed-off-by: Til Kaiser <mail@tk154.de>
---
 .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 20 ++++++++++++-------
 1 file changed, 13 insertions(+), 7 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 3372ed27cc8d..397aa5ca4992 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3991,7 +3991,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 				err = mvpp2_rx_refill(port, bm_pool, pp, pool);
 				if (err) {
 					netdev_err(port->dev, "failed to refill BM pools\n");
-					goto err_drop_frame;
+					goto err_drop_frame_retired;
 				}
 
 				ps.rx_packets++;
@@ -4010,6 +4010,8 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 			netdev_warn(port->dev, "skb build failed\n");
 			goto err_drop_frame;
 		}
+		if (pp)
+			skb_mark_for_recycle(skb);
 
 		/* If we have RX hardware timestamping enabled, grab the
 		 * timestamp from the queue and convert.
@@ -4023,13 +4025,16 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 		err = mvpp2_rx_refill(port, bm_pool, pp, pool);
 		if (err) {
 			netdev_err(port->dev, "failed to refill BM pools\n");
+			if (!pp)
+				dma_unmap_single_attrs(dev->dev.parent, dma_addr,
+						       bm_pool->buf_size,
+						       DMA_FROM_DEVICE,
+						       DMA_ATTR_SKIP_CPU_SYNC);
 			dev_kfree_skb_any(skb);
-			goto err_drop_frame;
+			goto err_drop_frame_retired;
 		}
 
-		if (pp)
-			skb_mark_for_recycle(skb);
-		else
+		if (!pp)
 			dma_unmap_single_attrs(dev->dev.parent, dma_addr,
 					       bm_pool->buf_size, DMA_FROM_DEVICE,
 					       DMA_ATTR_SKIP_CPU_SYNC);
@@ -4048,13 +4053,14 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 		continue;
 
 err_drop_frame:
-		dev->stats.rx_errors++;
-		mvpp2_rx_error(port, rx_desc);
 		/* Return the buffer to the pool */
 		if (rx_status & MVPP2_RXD_BUF_HDR)
 			mvpp2_buff_hdr_pool_put(port, rx_desc, pool, rx_status);
 		else
 			mvpp2_bm_pool_put(port, pool, dma_addr, phys_addr);
+err_drop_frame_retired:
+		dev->stats.rx_errors++;
+		mvpp2_rx_error(port, rx_desc);
 	}
 
 	if (xdp_ret & MVPP2_XDP_REDIR)
-- 
2.54.0

[PATCH net v2 4/4] net: mvpp2: build skb from XDP-adjusted data on XDP_PASS

[Til Kaiser]

When an XDP program uses bpf_xdp_adjust_head() or bpf_xdp_adjust_tail()
and then returns XDP_PASS, mvpp2 still builds the skb from fixed offsets
derived from the original RX descriptor. Packet geometry changes made by
the XDP program are therefore discarded before the skb reaches the stack.

Update rx_offset and rx_bytes from xdp.data and xdp.data_end for
XDP_PASS. This makes skb_reserve() and skb_put() reflect the packet seen
by XDP, and makes RX byte accounting for XDP_PASS follow the length of the
skb passed to the network stack.

Non-PASS verdicts continue to account the descriptor length because no skb
is passed up in those cases.

Fixes: 07dd0a7aae7f ("mvpp2: add basic XDP support")
Signed-off-by: Til Kaiser <mail@tk154.de>
---
 drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
index 397aa5ca4992..844f433975ed 100644
--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
+++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
@@ -3920,7 +3920,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 		unsigned int frag_size;
 		dma_addr_t dma_addr;
 		phys_addr_t phys_addr;
-		int pool, rx_bytes, err, ret;
+		int pool, rx_bytes, rx_offset, err, ret;
 		struct page *page;
 		void *data;
 
@@ -3933,6 +3933,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 		rx_status = mvpp2_rxdesc_status_get(port, rx_desc);
 		rx_bytes = mvpp2_rxdesc_size_get(port, rx_desc);
 		rx_bytes -= MVPP2_MH_SIZE;
+		rx_offset = MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM;
 		dma_addr = mvpp2_rxdesc_dma_addr_get(port, rx_desc);
 
 		pool = (rx_status & MVPP2_RXD_BM_POOL_ID_MASK) >>
@@ -3999,6 +4000,10 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 				continue;
 			}
 
+			/* Update offset and length to reflect any XDP adjustments. */
+			rx_offset = xdp.data     - data;
+			rx_bytes  = xdp.data_end - xdp.data;
+
 			metasize = xdp.data - xdp.data_meta;
 		}
 
@@ -4042,7 +4047,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
 		ps.rx_packets++;
 		ps.rx_bytes += rx_bytes;
 
-		skb_reserve(skb, MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM);
+		skb_reserve(skb, rx_offset);
 		skb_put(skb, rx_bytes);
 		if (metasize)
 			skb_metadata_set(skb, metasize);
-- 
2.54.0

Re: [PATCH net v2 0/4] net: mvpp2: fix XDP RX buffer handling

[Alexander Lobakin]

From: Til Kaiser <mail@tk154.de>
Date: Tue,  2 Jun 2026 18:46:31 +0200

> This is v2 of the earlier XDP_PASS fix. The XDP_PASS change is retained,
> and the series now also fixes related RX/XDP buffer handling issues found
> during review.
> 
> ---
> v1: https://lore.kernel.org/all/20260524122334.1730451-1-mail@tk154.de/
> 
> Changes in v2:
> - Fixed RX DMA sync range to account for RX headroom.
> - Limited XDP frame size to the actual RX buffer size.
> - Fixed refill error paths so retired buffers are not returned to BM.
> 
> Til Kaiser (4):
>   net: mvpp2: sync RX data at the hardware packet offset
>   net: mvpp2: limit XDP frame size to the RX buffer
>   net: mvpp2: do not return retired RX buffers to BM
>   net: mvpp2: build skb from XDP-adjusted data on XDP_PASS
> 
>  .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 38 ++++++++++++-------
>  1 file changed, 25 insertions(+), 13 deletions(-)

Series:

Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>

Thanks,
Olek

Re: [PATCH net v2 1/4] net: mvpp2: sync RX data at the hardware packet offset

[sashiko-bot]

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

Pre-existing issues:
- [High] Hardware address confusion in mvpp2_buff_hdr_pool_put leading to wild pointer dereference.
--

commit 5455df1ccac8168f900ec83f5414e617fb3ad72f
Author: Til Kaiser <mail@tk154.de>

net: mvpp2: sync RX data at the hardware packet offset

This commit modifies the DMA sync offset for received packets in mvpp2_rx.
It uses dma_sync_single_range_for_cpu with MVPP2_SKB_HEADROOM so the CPU
sync correctly aligns with the data written by the hardware.

> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index f442b874bb593..92a701f4fe3f5 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -3946,9 +3946,10 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
>  			dma_dir = DMA_FROM_DEVICE;
>  		}
>  
> -		dma_sync_single_for_cpu(dev->dev.parent, dma_addr,
> -					rx_bytes + MVPP2_MH_SIZE,
> -					dma_dir);
> +		dma_sync_single_range_for_cpu(dev->dev.parent, dma_addr,
> +					      MVPP2_SKB_HEADROOM,
> +					      rx_bytes + MVPP2_MH_SIZE,
> +					      dma_dir);
>  
>  		/* Buffer header not supported */
>  		if (rx_status & MVPP2_RXD_BUF_HDR)

[Severity: High]
This isn't a bug introduced by this patch, but when rx_status has
MVPP2_RXD_BUF_HDR set, this code jumps to err_drop_frame and eventually
calls mvpp2_buff_hdr_pool_put(). Does mvpp2_buff_hdr_pool_put() swap the
physical and DMA addresses?

Looking at mvpp2_buff_hdr_pool_put():

	phys_addr = mvpp2_rxdesc_dma_addr_get(port, rx_desc);
	dma_addr = mvpp2_rxdesc_cookie_get(port, rx_desc);

	do {
		buff_hdr = (struct mvpp2_buff_hdr *)phys_to_virt(phys_addr);

It appears that phys_addr is populated with a DMA address and dma_addr is
populated with the physical cookie.

On systems with an IOMMU where DMA addresses do not map 1:1 to physical
addresses, will calling phys_to_virt() on a DMA address cause a wild pointer
dereference? Could this also corrupt the hardware Buffer Manager pool when
passing these swapped addresses into mvpp2_bm_pool_put()?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602164635.62517-1-mail@tk154.de?part=1

Re: [PATCH net v2 2/4] net: mvpp2: limit XDP frame size to the RX buffer

[sashiko-bot]

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

Pre-existing issues:
- [High] Changing MTU to jumbo frames switches to shared buffers without detaching XDP, leading to NULL pointer dereference.
--

commit 6697a25a0b55fb9d610bfbe672d3935e951e1d53
Author: Til Kaiser <mail@tk154.de>

net: mvpp2: limit XDP frame size to the RX buffer

mvpp2 has short and long BM pools, and short pool buffers can be smaller
than PAGE_SIZE. The XDP path nevertheless initializes every xdp_buff with
PAGE_SIZE as frame size. This initializes the XDP buffer with
bm_pool->frag_size so XDP tailroom matches the actual buffer backing the
packet.

> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 92a701f4fe3f5..3372ed27cc8d6 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
[ ... ]
> @@ -3979,7 +3979,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
>  			else
>  				xdp_rxq = &rxq->xdp_rxq_long;
>  
> -			xdp_init_buff(&xdp, PAGE_SIZE, xdp_rxq);
> +			xdp_init_buff(&xdp, bm_pool->frag_size, xdp_rxq);
>  			xdp_prepare_buff(&xdp, data,
>  					 MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM,
>  					 rx_bytes, true);

[Severity: High]
This is a pre-existing issue, but is there a problem with XDP and jumbo
frames here?

If mvpp2_change_mtu() is called with an MTU that requires jumbo frames but is
smaller than MVPP2_MAX_RX_BUF_SIZE, it allows the MTU change and switches to
shared pools by calling mvpp2_bm_switch_buffers().

This destroys the page_pool structures and sets priv->percpu_pools to false,
but the XDP program remains attached.

Later, when packets arrive in mvpp2_rx():

	if (port->priv->percpu_pools) {
		pp = port->priv->page_pool[pool];
		dma_dir = page_pool_get_dma_dir(pp);
	} else {
		dma_dir = DMA_FROM_DEVICE;
	}

Because priv->percpu_pools is now false, pp remains NULL.

When mvpp2_run_xdp() is called with this NULL pp, and the XDP program returns
XDP_DROP, it unconditionally calls page_pool_put_page() with the NULL pp and
a non-page-pool page:

	case XDP_DROP:
		page = virt_to_head_page(xdp->data);
		page_pool_put_page(pp, page, sync, true);

Could this cause a kernel panic when XDP drops or redirects a packet after
an MTU change?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602164635.62517-1-mail@tk154.de?part=2

Re: [PATCH net v2 3/4] net: mvpp2: do not return retired RX buffers to BM

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Fixing the UAF introduces a permanent leak of hardware Buffer Manager (BM) pool slots on RX refill failure, leading to a permanent RX stall.
--

commit 0804789e54c7ef2fb92f8bc16ab030a2285b6149
Author: Til Kaiser <mail@tk154.de>

net: mvpp2: do not return retired RX buffers to BM

This patch splits the RX error handling path to avoid returning buffers
to the hardware Buffer Manager (BM) pool after they have been passed to
XDP or built into an skb.

> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 3372ed27cc8d6..397aa5ca4992c 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> @@ -3991,7 +3991,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
>  				err = mvpp2_rx_refill(port, bm_pool, pp, pool);
>  				if (err) {
>  					netdev_err(port->dev, "failed to refill BM pools\n");
> -					goto err_drop_frame;
> +					goto err_drop_frame_retired;

[Severity: High]
Does skipping the buffer return here cause a permanent hardware pool leak?

By jumping to err_drop_frame_retired, we no longer put a replacement buffer
into the hardware Buffer Manager (BM) pool. If mvpp2_rx_refill() repeatedly
fails under memory pressure, will this drain the BM pool slots to zero and
permanently stall packet reception?

To avoid returning an already-consumed buffer while keeping the BM pool
full, would it be safer to perform the buffer allocation and refill
before passing the original buffer to XDP?

[ ... ]

> @@ -4023,13 +4025,16 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
>  		err = mvpp2_rx_refill(port, bm_pool, pp, pool);
>  		if (err) {
>  			netdev_err(port->dev, "failed to refill BM pools\n");
> +			if (!pp)
> +				dma_unmap_single_attrs(dev->dev.parent, dma_addr,
> +						       bm_pool->buf_size,
> +						       DMA_FROM_DEVICE,
> +						       DMA_ATTR_SKIP_CPU_SYNC);
>  			dev_kfree_skb_any(skb);
> -			goto err_drop_frame;
> +			goto err_drop_frame_retired;

[Severity: High]
Does this path also permanently lose a hardware buffer slot?

Since the successfully built skb is freed and we jump to
err_drop_frame_retired, the hardware BM pool does not get replenished.

Could the refill be done before calling build_skb() so the original buffer
can be safely returned to the hardware pool if allocation fails?

[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602164635.62517-1-mail@tk154.de?part=3

Re: [PATCH net v2 4/4] net: mvpp2: build skb from XDP-adjusted data on XDP_PASS

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] Hardware checksum status is incorrectly applied to XDP-modified packets, bypassing network stack validation.
--

commit f1fdb866a6579f01cab52a8f590b1009e5b86b4d
Author: Til Kaiser <mail@tk154.de>

net: mvpp2: build skb from XDP-adjusted data on XDP_PASS

This commit updates the skb creation logic in the mvpp2 driver to account
for packet geometry changes made by XDP programs. It updates rx_offset and
rx_bytes from xdp.data and xdp.data_end for XDP_PASS packets.

> diff --git a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> index 397aa5ca4992c..844f433975edc 100644
> --- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c
> +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c

[ ... ]

> @@ -4042,7 +4047,7 @@ static int mvpp2_rx(struct mvpp2_port *port, struct napi_struct *napi,
>  		ps.rx_packets++;
>  		ps.rx_bytes += rx_bytes;
>  
> -		skb_reserve(skb, MVPP2_MH_SIZE + MVPP2_SKB_HEADROOM);
> +		skb_reserve(skb, rx_offset);
>  		skb_put(skb, rx_bytes);
>  		if (metasize)
>  			skb_metadata_set(skb, metasize);
>  		skb->ip_summed = mvpp2_rx_csum(port, rx_status);

[Severity: High]
If an XDP program modifies the packet (for example, by popping an
encapsulation header using bpf_xdp_adjust_head), is it safe to apply the
hardware's original checksum status to the modified skb here in mvpp2_rx?

The hardware validation of the outer L4 checksum might incorrectly be applied
to the inner packet, causing the network stack to inappropriately trust
CHECKSUM_UNNECESSARY. Should the driver clear the checksum status (for
example, setting it to CHECKSUM_NONE) if the XDP program modified the packet?

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260602164635.62517-1-mail@tk154.de?part=4

Re: [PATCH net v2 0/4] net: mvpp2: fix XDP RX buffer handling

[Marcin Wojtas]

Hi Tim,


śr., 3 cze 2026 o 15:55 Alexander Lobakin
<aleksander.lobakin@intel.com> napisał(a):
>
> From: Til Kaiser <mail@tk154.de>
> Date: Tue,  2 Jun 2026 18:46:31 +0200
>
> > This is v2 of the earlier XDP_PASS fix. The XDP_PASS change is retained,
> > and the series now also fixes related RX/XDP buffer handling issues found
> > during review.
> >
> > ---
> > v1: https://lore.kernel.org/all/20260524122334.1730451-1-mail@tk154.de/
> >
> > Changes in v2:
> > - Fixed RX DMA sync range to account for RX headroom.
> > - Limited XDP frame size to the actual RX buffer size.
> > - Fixed refill error paths so retired buffers are not returned to BM.
> >
> > Til Kaiser (4):
> >   net: mvpp2: sync RX data at the hardware packet offset
> >   net: mvpp2: limit XDP frame size to the RX buffer
> >   net: mvpp2: do not return retired RX buffers to BM
> >   net: mvpp2: build skb from XDP-adjusted data on XDP_PASS
> >
> >  .../net/ethernet/marvell/mvpp2/mvpp2_main.c   | 38 ++++++++++++-------
> >  1 file changed, 25 insertions(+), 13 deletions(-)
>
> Series:
>
> Reviewed-by: Alexander Lobakin <aleksander.lobakin@intel.com>
>

Tha changes look good, thank you.

Reviewed-by: Marcin Wojtas <marcin.s.wojtas@gmail.com>

Best regards,
Marcin

Re: [PATCH net v2 3/4] net: mvpp2: do not return retired RX buffers to BM

[Jakub Kicinski]

On Tue,  2 Jun 2026 18:46:34 +0200 Til Kaiser wrote:
> The RX refill failure path jumps to err_drop_frame, which returns the
> descriptor buffer to the hardware BM pool. That is only valid while the
> driver still owns the buffer.
> 
> After a non-PASS XDP verdict, mvpp2_run_xdp() may already have recycled,
> redirected, or queued the page for XDP_TX. After build_skb(), freeing the
> skb on refill failure also retires the data buffer. Returning either of
> those buffers to BM lets hardware DMA into memory that is no longer owned
> by the RX ring.
> 
> Split the error handling so buffers are returned to BM only while still
> owned by the driver. Once XDP or an skb owns the buffer, only account the
> RX error. Mark page-pool skbs for recycle before they can be freed on the
> refill failure path, and unmap non-page-pool buffers before freeing them.

As Gemini points out the driver seems to be following the "if I can't
allocate a new buffer I'll drop the packet and give the current buffer
back to the HW" flow. So after your change on allocation error we're
permanently leaking a slot on in the buffer pool. Leaking as in it will
never be filled, if it happens enough times the pool will be empty,
and no Rx can happen.
-- 
pw-bot: cr