Re: [PATCH net v4] xsk: Do not free ZC Rx buffer when the Rx ring is full

[Maciej Fijalkowski <maciej.fijalkowski@intel.com>]

On Thu, Nov 12, 2026 at 07:58:51AM +0000, Marcin Knap wrote:
> >But what's the plan for fixing those redirect targets?
> >I think it'd be much better if we had one series which
> >addresses all the cases, which AI can review...
> >If there's consensus that xdp_convert_zc_to_xdp_frame()
> >can be trivially handled later let's document that (and
> >how) in the commit message?
> 
> Thanks for the review. I looked at the devmap/cpumap/ifindex path. The
> fix I have in mind is local to xdp_do_redirect(): for zero-copy buffers,
> copy into the new frame without freeing the ZC buffer, free the ZC
> buffer only once __xdp_do_redirect_frame() has succeeded, and free the
> copied frame on failure. That gives the same rule as the XSKMAP path
> after this patch (on error the caller still owns the buffer) and also
> fixes the leak of the copied page. xdp_convert_zc_to_xdp_frame() would
> stay as it is, since its XDP_TX users (e.g. mlx5) rely on it freeing
> the buffer.

Hmm. So it seems like currently, when we managed to properly copy from zc
the 'normal' page and redirect failed, we would interpret this as (based
on ice implementation, not sure about other zc drivers) ICE_XDP_CONSUMED
which would do another xsk_buff_free() which would be a no-op on this
xdp_buff at this point but 'normal' page would indeed leak?

> 
> I'm away from Monday for about a month and won't be able to drive that
> change and its review properly before then, so I'd rather keep this
> series to the XSKMAP fix and document the plan in the commit message,
> as you suggested. v5 will have that. I'm happy to pick up the redirect
> fix when I'm back, unless someone wants to take it earlier.
> 
> Regards,
> Marcin Knap