Mina Almasry says: ==================== net: unify symmetric netmem and page_pool refcounting 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@secunet.com/ [1] v2: https://lore.kernel.org/netdev/20261012082148.1698596-1-almasrymina@google.com/ v1: https://lore.kernel.org/netdev/20261010083935.3274178-1-almasrymina@google.com/ ==================== Link: https://patch.msgid.link/20261014173945.373295-1-almasrymina@google.com Signed-off-by: Paolo Abeni <pabeni@redhat.com>