From: Jakub Kicinski kuba@kernel.org
[ Upstream commit f3b52167a0cb23b27414452fbc1278da2ee884fc ]
Driver authors often forget to add GFP_NOWARN for page allocation from the datapath. This is annoying to users as OOMs are a fact of life, and we pretty much expect network Rx to hit page allocation failures during OOM. Make page pool add GFP_NOWARN for ATOMIC allocations by default.
Reviewed-by: Mina Almasry almasrymina@google.com Link: https://patch.msgid.link/20250912161703.361272-1-kuba@kernel.org Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org ---
LLM Generated explanations, may be completely bogus:
Based on my extensive research and analysis of this commit, here is my determination:
## **BACKPORT RECOMMENDATION: YES**
## Detailed Analysis
### What This Commit Does
This commit adds the `__GFP_NOWARN` flag to GFP_ATOMIC allocations in the page_pool subsystem by modifying the `__page_pool_alloc_netmems_slow()` function in `net/core/page_pool.c`. The change is minimal (6 lines) and specifically targets atomic allocations that occur during network packet reception in NAPI context.
**Code change at net/core/page_pool.c:554-558:** ```c + /* Unconditionally set NOWARN if allocating from NAPI. + * Drivers forget to set it, and OOM reports on packet Rx are useless. + */ + if ((gfp & GFP_ATOMIC) == GFP_ATOMIC) + gfp |= __GFP_NOWARN; ```
This modification affects both bulk page allocations (via `alloc_pages_bulk_node`) and high-order page allocations (via `__page_pool_alloc_page_order`).
### Historical Context and Broader Pattern
Through extensive git history analysis, I discovered this is part of a **systematic effort by Jakub Kicinski** to address OOM warnings in the network stack:
1. **March 2024** (commit 6e9b01909a811): Modified `napi_alloc_skb()` to hardcode `GFP_ATOMIC | __GFP_NOWARN` - Commit message stated: *"the resulting OOM warning is the top networking warning in our fleet"* (Meta's production environment) - Rationale: *"allocation failures in atomic context will happen, and printing warnings in logs, effectively for a packet drop, is both too much and very likely non-actionable"*
2. **August 2024** (commit c89cca307b209): Added `__GFP_NOWARN` to skbuff ingress allocations - Similar rationale: *"build_skb() and frag allocations done with GFP_ATOMIC will fail in real life, when system is under memory pressure, and there's nothing we can do about that. So no point printing warnings."*
3. **September 2025** (this commit): Extends the same principle to page_pool allocations
### Existing Precedent Validates This Approach
My code research revealed:
**Helper function already uses this pattern** (include/net/page_pool/helpers.h:92-96): ```c static inline struct page *page_pool_dev_alloc_pages(struct page_pool *pool) { gfp_t gfp = (GFP_ATOMIC | __GFP_NOWARN); return page_pool_alloc_pages(pool, gfp); } ```
**Drivers manually adding NOWARN since 2022**: - `drivers/net/ethernet/mediatek/mtk_eth_soc.c:1916` - Added in July 2022 (commit 23233e577ef973) - `drivers/net/vmxnet3/vmxnet3_drv.c:1425` - Also includes manual NOWARN
This demonstrates driver authors were already aware of the need for `__GFP_NOWARN` with page_pool allocations, validating the approach.
### Why This Should Be Backported
**1. Fixes Real User-Visible Issue** - OOM warnings during network Rx are non-actionable and create log spam - Confirmed as "top networking warning" at large-scale deployments (Meta) - OOM during memory pressure is expected behavior, not an error condition - Warnings provide no value but clutter logs and may trigger false alarms
**2. Minimal Risk** - Only 6 lines of code added to a single function - Only suppresses warning messages, doesn't change allocation behavior - Allocation failures are still detected and properly handled by drivers - Network stack provides proper statistics via qstats (rx-alloc-fail counter) - No change to actual page allocation logic or error handling paths
**3. No Regressions Found** - No subsequent commits fixing or reverting this change - No Fixes: tags referencing this commit - Commit has been in mainline since September 2025 with no reported issues - Subsequent commit (a1b501a8c6a87) is unrelated (pool size clamping)
**4. Makes Behavior Consistent** - Aligns with existing helper function behavior - Removes burden from driver authors who often forget this flag - Prevents inconsistency where some drivers add NOWARN and others don't - Follows established pattern from napi_alloc_skb() and skbuff allocations
**5. Meets Stable Kernel Criteria** - ✅ Fixes a real bug that bothers people (log spam annoys users and operators) - ✅ Obviously correct (trivial change, well-understood semantics) - ✅ Small and self-contained (6 lines, single file) - ✅ No regression risk (only suppresses warnings) - ✅ No API changes (internal implementation detail)
### Technical Correctness
**GFP_ATOMIC context** (from include/linux/gfp_types.h:316-318):
"GFP_ATOMIC users can not sleep and need the allocation to succeed. A
lower watermark is applied to allow access to 'atomic reserves'."
**__GFP_NOWARN semantics** (from include/linux/gfp_types.h:274):
"__GFP_NOWARN suppresses allocation failure reports."
The change is semantically correct: When page_pool allocates pages in atomic context (NAPI), allocation failures are expected during OOM and warnings serve no purpose. The allocation failure is still detected and handled - only the noisy warning is suppressed.
### Why Not Explicitly Tagged for Stable
While the commit lacks a `Cc: stable` tag, this doesn't necessarily mean it shouldn't be backported. Examining similar commits: - Neither the napi_alloc_skb nor skbuff NOWARN commits had explicit stable tags - Quality-of-life improvements often aren't tagged by authors but are valuable for stable trees - Stable backport decisions should be based on technical merit and user benefit
### Potential Concerns Addressed
**"Does this hide real bugs?"** No - drivers still detect and handle allocation failures. The difference is only in logging.
**"Could this affect debugging?"** Minimal impact - allocation failures are tracked via qstats. OOM warnings during memory pressure are expected, not diagnostic.
**"Is this actually a bug fix?"** Yes - it fixes the "bug" of annoying, non-actionable log spam that affects production deployments at scale.
### Conclusion
This commit should be backported because it: 1. Solves a real, annoying user-visible problem (confirmed at production scale) 2. Has essentially zero risk (only suppresses warnings) 3. Is part of a well-vetted, systematic improvement 4. Makes the page_pool behavior consistent with established patterns 5. Reduces operational burden and log noise
While this is more of a quality-of-life improvement than a critical functional fix, the combination of high user benefit, zero risk, and strong technical justification makes it a good candidate for stable backporting.
**Final Answer: YES** - This commit should be backported to stable kernel trees.
net/core/page_pool.c | 6 ++++++ 1 file changed, 6 insertions(+)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c index 19c92aa04e549..e224d2145eed9 100644 --- a/net/core/page_pool.c +++ b/net/core/page_pool.c @@ -596,6 +596,12 @@ static noinline netmem_ref __page_pool_alloc_netmems_slow(struct page_pool *pool netmem_ref netmem; int i, nr_pages;
+ /* Unconditionally set NOWARN if allocating from NAPI. + * Drivers forget to set it, and OOM reports on packet Rx are useless. + */ + if ((gfp & GFP_ATOMIC) == GFP_ATOMIC) + gfp |= __GFP_NOWARN; + /* Don't support bulk alloc for high-order pages */ if (unlikely(pp_order)) return page_to_netmem(__page_pool_alloc_page_order(pool, gfp));