I had a very hard time creating the request I submitted, and don’t have the time to try and do that again. If you think it is a worthy change you can incorporate it some other way.
> On Sep 11, 2026, at 7:12 AM, Simon Horman <[email protected]> wrote: > > On Thu, Sep 10, 2026 at 11:17:47AM -0400, Gunter Woytowitz wrote: >> mana_create_rxq() registers MEM_TYPE_PAGE_POOL for the rxq >> unconditionally, so every buffer XDP can see must be owned by that >> page_pool: on XDP_REDIRECT the frame is freed through __xdp_return() >> -> page_pool_put_full_page(). >> >> mana_xdp_set() assigns apc->bpf_prog before calling >> mana_pre_alloc_rxbufs(), which allocates with dev_alloc_pages(), and >> mana_fill_rx_oob() prefers those buffers whenever mpc->rxbufs_pre is >> set, leaving from_pool false. So for a port that is up when a program >> is attached, the entire re-created ring is filled with pages the >> page_pool does not own. >> >> The page_pool then sees pp_ref_count == 0 when such a frame is >> returned, so the atomic_long_sub_return() in page_pool_unref_netmem() >> goes negative and trips its WARN_ON(ret < 0), once per redirected >> frame. Observed on a 5.14-based distro kernel, where that warning sits >> at helpers.h:269: >> >> WARNING: CPU: 3 PID: 0 at include/net/page_pool/helpers.h:269 >> __xdp_return+0x2b3/0x2c0 >> mana_process_rx_cqe -> mana_run_xdp -> mana_rx_skb -> xsk_map_redirect >> -> __xdp_return >> >> On a VM booted with console=ttyS0 the resulting stack traces peg the >> console thread and the machine becomes unusable. >> >> Fill from the page_pool when a program is attached, using >> mana_xdp_get() -- the predicate mana_get_rxbuf_cfg() already uses to >> choose the XDP buffer geometry. With no program attached nothing >> changes, so the pre-allocation still does its job of keeping >> mana_attach() from failing on allocation. >> >> Leaving the pre-allocated buffers unconsumed is safe: >> mana_pre_dealloc_rxbufs() dma-unmaps and put_page()s the remainder, >> and every caller (mana_xdp_set(), mana_change_mtu(), and both ethtool >> ring and channel paths) already runs it after mana_attach(). >> >> The rxq->xdp_save_va reuse in mana_get_rxfrag() also leaves from_pool >> false, but that cache is fed only by the drop path's non-pool branch, >> which this change makes unreachable while a program is attached, so >> it needs no fix. >> >> Found and fixed on a 5.14-based distro kernel running AF_XDP over >> MANA in copy mode: 24M+ redirected frames with no warnings, where the >> unpatched driver warned on essentially every redirected frame. All of >> the code involved is unchanged in mainline. >> >> Fixes: b1d13f7a3b53 ("net: mana: Add page pool for RX buffers") >> Signed-off-by: Gunter Woytowitz <[email protected]> > > Unfortunately the CI failed to apply this patch to net. > Which is curious, because I am able to apply it locally. > > But perhaps it would be best to (rebase and?) repost > after waiting for the usual 24h[*] to elapse. > > [*] https://docs.kernel.org/process/maintainer-netdev.html > > -- > pw-bot: changes-requested This email may contain confidential and privileged information and is intended solely for the use of the addressee(s). Unless you are the addressee or are authorized to receive messages for the addressee, you may not use, copy, disseminate, or disclose the information or any attachments to any third party. If you have received this correspondence in error, please notify the sender immediately and delete this email. Your cooperation and understanding are greatly appreciated. Attention Federal Customers: Please note this email platform is NOT approved to communicate (send or receive) CUI. For questions on the approved system to communicate CUI, please contact your designated Vcinity Representative.
