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

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

[Aaron Tomlin]

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.

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);
 			adapter->rxdataring_enabled = false;
 		}
 	} else {
-- 
2.51.0

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@huawei.com>

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

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

[Aaron Tomlin]

On Tue, Feb 24, 2026 at 05:02:55PM +0800, Jijie Shao wrote:
> 
> 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>

Hi Jijie,

Thank you for your feedback.

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

Agreed.


Kind regards,
-- 
Aaron Tomlin