Re: [PATCH] vmxnet3: Suppress page allocation warning for massive Rx Data ring
From: Jijie Shao <shaojijie@huawei.com>
Date: 2026-02-24 09:03:00
Also in:
lkml
on 2026/2/23 22:56, Aaron Tomlin wrote:
The vmxnet3 driver supports an Rx Data ring (rx-mini) to optimise the
processing of small packets. The size of this ring's DMA-coherent memory
allocation is determined by the product of the primary Rx ring size and
the data ring descriptor size:
sz = rq->rx_ring[0].size * rq->data_ring.desc_size;
When a user configures the maximum supported parameters via ethtool
(rx_ring[0].size = 4096, data_ring.desc_size = 2048), the required
contiguous memory allocation reaches 8 MB (8,388,608 bytes).
In environments lacking Contiguous Memory Allocator (CMA),
dma_alloc_coherent() falls back to the standard zone buddy allocator. An
8 MB allocation translates to a page order of 11, which strictly exceeds
the default MAX_PAGE_ORDER (10) on most architectures.
Consequently, __alloc_pages_noprof() catches the oversize request and
triggers a loud kernel warning stack trace:
WARN_ON_ONCE_GFP(order > MAX_PAGE_ORDER, gfp)
This warning is unnecessary and alarming to system administrators because
the vmxnet3 driver already handles this allocation failure gracefully.
If dma_alloc_coherent() returns NULL, the driver safely disables the
Rx Data ring (adapter->rxdataring_enabled = false) and falls back to
standard, streaming DMA packet processing.
To resolve this, append the __GFP_NOWARN flag to the dma_alloc_coherent()
gfp_mask. This instructs the page allocator to silently fail the
allocation if it exceeds order limits or memory is too fragmented,
preventing the spurious warning stack trace.This seems to be a suitable solution. I see many drivers appending the __GFP_NOWARN flag to the dma_alloc_coherent() gfp_mask. Reviewed-by: Jijie Shao <shaojijie@huawei.com>
quoted hunk ↗ jump to hunk
Furthermore, enhance the subsequent netdev_err() fallback message to include the requested allocation size. This provides critical debugging context to the administrator (e.g., revealing that an 8 MB allocation was attempted and failed) without making hardcoded assumptions about the state of the system's configurations. Signed-off-by: Aaron Tomlin <atomlin@atomlin.com> --- drivers/net/vmxnet3/vmxnet3_drv.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)diff --git a/drivers/net/vmxnet3/vmxnet3_drv.c b/drivers/net/vmxnet3/vmxnet3_drv.c index 0572f6a9bdb6..0d43210de625 100644 --- a/drivers/net/vmxnet3/vmxnet3_drv.c +++ b/drivers/net/vmxnet3/vmxnet3_drv.c@@ -2268,10 +2268,10 @@ vmxnet3_rq_create(struct vmxnet3_rx_queue *rq, struct vmxnet3_adapter *adapter) rq->data_ring.base = dma_alloc_coherent(&adapter->pdev->dev, sz, &rq->data_ring.basePA, - GFP_KERNEL); + GFP_KERNEL | __GFP_NOWARN); if (!rq->data_ring.base) { netdev_err(adapter->netdev, - "rx data ring will be disabled\n"); + "Failed to allocate %zu bytes, rx data ring will be disabled\n", sz);
Here, it seems more appropriate to use "failed to".
adapter->rxdataring_enabled = false;
}
} else {