Re: [PATCH net-next v3 0/6] net: unify symmetric netmem and page_pool refcounting

[Stanislav Fomichev]

On 10/14, Mina Almasry wrote:
> netmems (pages and net_iovs) have two independent refcounts: a non-pp
> refcount (page._refcount or binding->ref) governing backing memory
> lifetime, and pp_ref_count governing recycling within a page_pool while
> page_pool holds a single backing non-pp reference. SKBs with
> pp_recycle=1 own pp_ref_count references on page_pool fragments; SKBs
> with pp_recycle=0 own non-pp references.
> 
> Core helpers currently mix these two refcounts asymmetrically:
> skb_frag_ref() always increments the non-pp refcount via get_netmem(),
> whereas skb_frag_unref() decrements pp_ref_count when skb->pp_recycle
> is set. Any path that refs a fragment on a pp_recycle=1 SKB (or unrefs
> with a hardcoded recycle=false) increments one counter and decrements
> the other, leaking the backing memory while underflowing pp_ref_count
> (e.g., IP-TFS [1], skb_split(), skb_shift(), and cloned SKB uncloning).
> Unclear core APIs also led drivers and ULPs to open-code pp_ref_count
> manipulations or add one-off helpers like skb_pp_frag_ref().
> 
> Unify fragment refcounting into symmetric pairs where each layer clearly
> specifies which refcount it touches:
> 
> - Non-PP refcount: get/put_page(), get/put_net_iov(), get/put_netmem()
> - PP refcount:     napi_pp_get/put_page()
> - SKB netmem:      skb_netmem_ref/unref(netmem, recycle)
> - SKB fragment:    skb_frag_ref/unref(skb, f)
> 
> Found by code inspection while reviewing [1] and confirmed with the KUnit
> tests in patch 6; not observed in production. Driver and ULP call-site
> changes are compile-tested only.
> 
> Link: https://lore.kernel.org/netdev/xfrm-iptfs-pp_ref_count-underflow-v4-1-912fa72106f0@xxxxxxxxxxx/ [1]
> 
> ---
> v3:
> - Linearize straddling output segments in skb_segment() when frag_list
>   SKBs mix pp_recycle flags instead of clearing NETIF_F_SG, and add a
>   KUnit regression test (Sashiko).
> - Link to v2: https://lore.kernel.org/netdev/20261012082148.1698596-1-almasrymina@xxxxxxxxxx/

Acked-by: Stanislav Fomichev <sdf@xxxxxxxxxxx>