Both netconsole and netpoll keep a small preallocated pool of skbs
(skb_pool) so they can still get a buffer under memory pressure.

On the hot path they first attempt a normal GFP_ATOMIC allocation and only
fall back to the pool when that fails, keeping the pool as a last resort.

This is where the problem happens. If alloc_skb() fails, we now have
more than 100 message coming from the page=0 failure, which consumes the
scarce pool of skb, making the real issue disappear.

So the noise (memory allocation failure) deplets the SKB buffer and crowds out
the real message we were trying to deliver.

This is happening on the Meta fleet. The stack trace looks like:

  pr/netcon_ext0: page allocation failure: order:0, mode:0x40820(GFP_ATOMIC|__GFP_COMP), nodemask=(null),cpuset=/,mems_allowed=0
  ...
  dump_stack_lvl
  warn_alloc
  __alloc_pages_slowpath
  __alloc_frozen_pages_noprof
  alloc_pages_mpol
  alloc_slab_page
  allocate_slab
  kmem_cache_alloc_node_noprof
  __alloc_skb
  send_udp
  netconsole_write
  nbcon_emit_next_record
  nbcon_emit_one
  nbcon_kthread_func
  kthread

Solution: Do not warn if netconsole/netpoll fails to allocate these SKBs. Pass
__GFP_NOWARN on these best-effort allocations -- both the hot-path attempt in
netconsole's find_skb() and the pool refill in netpoll's refill_skbs() -- and
let the existing fallback paths do their job quietly. The allocation will
happen on SKB refill workqueue.

Given I am touching this code, if alloc_skb() fails, reschedule the
workqueue to try later.

Signed-off-by: Breno Leitao <leitao@debian.org>
---
Breno Leitao (2):
      netconsole: do not warn when the best-effort skb allocation fails
      netpoll: do not warn when the best-effort pool refill fails

 drivers/net/netconsole.c | 2 +-
 net/core/netpoll.c       | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
---
base-commit: 3d5670d672ae08b8c534b7beed6f57c8b44e7b43
change-id: 20260629-netpoll_no_warn-20174d15bcd3

Best regards,
-- 
Breno Leitao [off-list ref]