Re: [PATCH net-next v2 3/6] net: skbuff: replace skb_page_unref() and __skb_frag_unref() with skb_netmem_unref()

[Mina Almasry]

On Tue, Oct 13, 2026 at 1:34 AM <netdev-bot+sashiko@xxxxxxxxxx> wrote:
>
> Thank you for your contribution! Sashiko AI review found 2 potential
> issue(s) to consider.
>
> Critical: 0 · High: 0 · Medium: 1 · Low: 1
>
> If you believe none of the issues are legitimate, please reply to each
> issue of Medium severity or higher and explain why the AI is wrong.
> If any of them are legitimate and you plan to respin, please let patchwork
> know by including "pw-bot: cr" as a separate line at the end of your reply
> (one such reply per series is enough).
>
> - [Medium] The patch fixes a real page refcount bug on mlx4's RX error
>   path but has no Fixes: tag, and the fix is folded into a tree-wide API…
> - [Low] At this commit, the new kernel-doc for skb_netmem_unref() in
>   include/linux/skbuff_ref.h says it is the "Counterpart to…
>
> --
>
> net: skbuff: replace skb_page_unref() and __skb_frag_unref() with skb_netmem_unref()
>
> This patch replaces skb_page_unref() and __skb_frag_unref() with a single
> helper, skb_netmem_unref(netmem, recycle). The SKB-owned fragment unrefs
> in mlx4, sky2, tls_strp and skb_shift() now use skb_frag_unref(), so they
> follow skb->pp_recycle. tls_device's destroy_record() now calls
> put_netmem() directly.
>
> > diff --git a/drivers/net/ethernet/mellanox/mlx4/en_rx.c b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> > index 96f97fa0f5489..fe18606c2ab55 100644
> > --- a/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> > +++ b/drivers/net/ethernet/mellanox/mlx4/en_rx.c
> > @@ -497,7 +497,7 @@ static int mlx4_en_complete_rx_desc(struct mlx4_en_priv *priv,
> >  fail:
> >       while (nr > 0) {
> >               nr--;
> > -             __skb_frag_unref(skb_shinfo(skb)->frags + nr, false);
> > +             skb_frag_unref(skb, nr);
> >       }
> >       return 0;
> >  }
>
> [Severity: Medium]
> This looks like a real fix for mlx4. Should it have a Fixes: tag and go
> in separately from the API rework?
>

I think there were a lot of latent bugs in the refcounting, and if
possible I'd like to fix them and make the refcounting more consistent
rather than split them up. A lot of the fixes depend on reworked or
introduced new consistent and symetric helpers.

>
> [Severity: Low]
> This isn't a bug, but are these kernel-doc references accurate at this
> point in the series?
>

Very low prio nit. The comment becomes consistent later.


-- 
Thanks,
Mina