Re: [PATCH] vmxnet3: Suppress page allocation warning for massive Rx Data ring

[Jijie Shao]

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@xxxxxxxxxx>

> 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@xxxxxxxxxxx>
> ---
>   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 {