Net drivers request GFP flags according to both the current context and
the device constraints, but the XArray entry itself is by no mean used
by the device. Passing though device constraints to XArray allocation is
a bug and will be warned and fixed up by slab, e.g.:

    Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x82820 (GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC). Fix your code!
    CPU: 2 UID: 0 PID: 1071629 Comm: kworker/u80:1 Not tainted 7.2.0-rc7+ #1 PREEMPT(lazy)
    Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN27WW 10/20/2025
    Workqueue: mt76 mt792x_pm_wake_work [mt792x_lib]
    Call Trace:
     <TASK>
     dump_stack_lvl+0x6e/0x90
     kmalloc_fix_flags+0x4d/0x6a
     refill_objects+0x10a/0x330
     __pcs_replace_empty_main+0x292/0x5c0
     kmem_cache_alloc_lru_noprof+0x4c2/0x680
     ? __xas_nomem+0x3a/0x120
     __xas_nomem+0x3a/0x120
     __xa_alloc+0xd4/0x190
     page_pool_dma_map+0xef/0x400
     __page_pool_alloc_netmems_slow+0xed/0x480
     ? lock_release+0x280/0x490
     page_pool_alloc_frag_netmem+0xe0/0x3a0
     page_pool_alloc_frag+0xe/0x20
     mt76_dma_rx_fill_buf+0x1f6/0x580 [mt76]
     mt76_dma_rx_reset+0x1cf/0x230 [mt76]
     mt792x_wpdma_reset+0x183/0x1b0 [mt792x_lib]
     mt792x_wpdma_reinit_cond+0x5e/0xa0 [mt792x_lib]
     mt792xe_mcu_drv_pmctrl+0x28/0x60 [mt792x_lib]
     mt792x_mcu_drv_pmctrl+0x3e/0x90 [mt792x_lib]
     mt792x_pm_wake_work+0x2d/0x1d0 [mt792x_lib]
     ? process_one_work+0x20e/0x600
     process_one_work+0x230/0x600
     ? process_one_work+0x256/0x600
     worker_thread+0x1ec/0x3c0
     ? rescuer_thread+0x610/0x610
     kthread+0xf2/0x130
     ? kthread_affine_node+0x140/0x140
     ret_from_fork+0x2a5/0x380
     ? kthread_affine_node+0x140/0x140
     ret_from_fork_asm+0x11/0x20
     </TASK>

Currently mt76 and stmmac may allocate page pool pages with GFP_DMA32.

Fix it by removing zone/policy GFP flags when allocating XArray entries.
This is inspired by commit 96d578088085 ("iommu/dma: Use the gfp
parameter in __iommu_dma_alloc_noncontiguous()").

Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool")
Signed-off-by: Rong Zhang <i@rong.moe>
---
 net/core/page_pool.c | 7 +++++++
 1 file changed, 7 insertions(+)

diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 50ee550fef73..8f8956fb061b 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -484,6 +484,13 @@ static int page_pool_register_dma_index(struct page_pool *pool,
 	if (unlikely(!PP_DMA_INDEX_BITS))
 		goto out;
 
+	/*
+	 * Drivers request GFP flags according to both the current context and
+	 * the device constraints, but the XArray entry itself is by no mean
+	 * used by the device, so remove zone/policy flags.
+	 */
+	gfp &= ~(__GFP_DMA | __GFP_DMA32 | __GFP_HIGHMEM | __GFP_COMP);
+
 	if (in_softirq())
 		err = xa_alloc(&pool->dma_mapped, &id, netmem_to_page(netmem),
 			       PP_DMA_INDEX_LIMIT, gfp);

---
base-commit: 91ec2035134982b98fab0609a9fd8480e8217dc1
change-id: f32fa2b0-page-pool-xa-drop-dma32-c1f34ba681b7

Thanks,
Rong

Rong Zhang <i@rong.moe> writes:

> Net drivers request GFP flags according to both the current context and
> the device constraints, but the XArray entry itself is by no mean used
> by the device. Passing though device constraints to XArray allocation is
> a bug and will be warned and fixed up by slab, e.g.:
>
>     Unexpected gfp: 0x4 (GFP_DMA32). Fixing up to gfp: 0x82820 (GFP_ATOMIC|__GFP_NOWARN|__GFP_NOMEMALLOC). Fix your code!
>     CPU: 2 UID: 0 PID: 1071629 Comm: kworker/u80:1 Not tainted 7.2.0-rc7+ #1 PREEMPT(lazy)
>     Hardware name: LENOVO 21Q4/LNVNB161216, BIOS PXCN27WW 10/20/2025
>     Workqueue: mt76 mt792x_pm_wake_work [mt792x_lib]
>     Call Trace:
>      <TASK>
>      dump_stack_lvl+0x6e/0x90
>      kmalloc_fix_flags+0x4d/0x6a
>      refill_objects+0x10a/0x330
>      __pcs_replace_empty_main+0x292/0x5c0
>      kmem_cache_alloc_lru_noprof+0x4c2/0x680
>      ? __xas_nomem+0x3a/0x120
>      __xas_nomem+0x3a/0x120
>      __xa_alloc+0xd4/0x190
>      page_pool_dma_map+0xef/0x400
>      __page_pool_alloc_netmems_slow+0xed/0x480
>      ? lock_release+0x280/0x490
>      page_pool_alloc_frag_netmem+0xe0/0x3a0
>      page_pool_alloc_frag+0xe/0x20
>      mt76_dma_rx_fill_buf+0x1f6/0x580 [mt76]
>      mt76_dma_rx_reset+0x1cf/0x230 [mt76]
>      mt792x_wpdma_reset+0x183/0x1b0 [mt792x_lib]
>      mt792x_wpdma_reinit_cond+0x5e/0xa0 [mt792x_lib]
>      mt792xe_mcu_drv_pmctrl+0x28/0x60 [mt792x_lib]
>      mt792x_mcu_drv_pmctrl+0x3e/0x90 [mt792x_lib]
>      mt792x_pm_wake_work+0x2d/0x1d0 [mt792x_lib]
>      ? process_one_work+0x20e/0x600
>      process_one_work+0x230/0x600
>      ? process_one_work+0x256/0x600
>      worker_thread+0x1ec/0x3c0
>      ? rescuer_thread+0x610/0x610
>      kthread+0xf2/0x130
>      ? kthread_affine_node+0x140/0x140
>      ret_from_fork+0x2a5/0x380
>      ? kthread_affine_node+0x140/0x140
>      ret_from_fork_asm+0x11/0x20
>      </TASK>
>
> Currently mt76 and stmmac may allocate page pool pages with GFP_DMA32.
>
> Fix it by removing zone/policy GFP flags when allocating XArray entries.
> This is inspired by commit 96d578088085 ("iommu/dma: Use the gfp
> parameter in __iommu_dma_alloc_noncontiguous()").
>
> Fixes: ee62ce7a1d90 ("page_pool: Track DMA-mapped pages and unmap them when destroying the pool")
> Signed-off-by: Rong Zhang <i@rong.moe>

Reviewed-by: Toke Høiland-Jørgensen <toke@redhat.com>