On Tue, Feb 03, 2026 at 11:53:34AM +0100, Larysa Zaremba wrote:
> The only user of frag_size field in XDP RxQ info is
> bpf_xdp_frags_increase_tail(). It clearly expects truesize instead of DMA
> write size. Different assumptions in enetc driver configuration lead to
> negative tailroom.
>
> Set frag_size to the same value as frame_sz.
>
> Fixes: 2768b2e2f7d2 ("net: enetc: register XDP RX queues with frag_size")
> Reviewed-by: Aleksandr Loktionov <[email protected]>
> Signed-off-by: Larysa Zaremba <[email protected]>
> ---
> drivers/net/ethernet/freescale/enetc/enetc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/ethernet/freescale/enetc/enetc.c
> b/drivers/net/ethernet/freescale/enetc/enetc.c
> index 53b26cece16a..389331571d9e 100644
> --- a/drivers/net/ethernet/freescale/enetc/enetc.c
> +++ b/drivers/net/ethernet/freescale/enetc/enetc.c
> @@ -3465,7 +3465,7 @@ static int enetc_int_vector_init(struct enetc_ndev_priv
> *priv, int i,
> priv->rx_ring[i] = bdr;
>
> err = __xdp_rxq_info_reg(&bdr->xdp.rxq, priv->ndev, i, 0,
> - ENETC_RXB_DMA_SIZE_XDP);
> + ENETC_RXB_TRUESIZE);
> if (err)
> goto free_vector;
>
> --
> 2.52.0
>
Reviewed-by: Vladimir Oltean <[email protected]>
Tested-by: Vladimir Oltean <[email protected]>
Thanks! This is an extremely subtle corner case. I appreciate the patch
and explanation.
I did run tests on the blamed commit (which I still have), but to catch
a real issue in a meaningful way it would have been required to have a
program which calls bpf_xdp_adjust_tail() with a very large offset.
I'm noting that I'm seeing the WARN_ON() much easier after your fix, but
before, it was mostly inconsequential for practical cases.
Namely, the ENETC truesize is 2048, and XDP_PACKET_HEADROOM is 256.
First buffers also contain the skb_shared_info (320 bytes), while
subsequent buffers don't.
Maybe the situation for Intel NICs is different, but we don't have the
ability to tell ENETC "you have this buffer size at your disposal for
initial buffers, and this other size for non-initial buffers". So we
just tell the NIC to DMA a maximum of 1472 bytes per buffer, as if all
buffers had skb_shared_info which shouldn't be overwritten.
That means that in non-initial buffers, there is plenty of tailroom due
to the space unused for skb_shared_info, space which bpf_xdp_adjust_tail()
can safely grow into.
So as long as the tail doesn't grow by more than 320 bytes, this growth
operation is actually safe even with the wrong rxq->frag_size (tailroom
pessimistically overestimated until it becomes that unrepresentable
negative value).
My tests were with bpf_xdp_adjust_tail(4)...
I have just one nitpick about this series: your patch order *introduces*
a bug for me which didn't really exist before for practical scenarios
(as explained above), since it fixes the offset > tailroom test to
return -EINVAL in patch 1/6, and then it fixes the driver in patch 6/6.
Normally, you'd fix the driver first, and then you'd fix the bad
condition in the core that was sidestepped, so that you don't introduce
regressions visible in "git bisect". I don't think that's major in this
case, so it's up to maintainers really if they request you to resend for
this or not.
