Do not latch these flags, they should be re-evaluated for each iteration of the loop. Concretely, rxq->free_count is incremented during the loop so the __GFP_NOWARN decision may be stale. There may be other reasons to require the re-evaluation too. Suggested-by: Stanislaw Gruszka Link: https://lore.kernel.org/all/20260327115739.GB16800@wp.pl/ Signed-off-by: Brendan Jackman --- Transparency note: I am 100% taking Stanislaw's word for this. The bug being fixed here hasn't been reproduced and I don't have a way to test this patch at all. It does seem to make sense to me though and, well, Stanislaw is the mantainer :) --- drivers/net/wireless/intel/iwlegacy/3945-mac.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/net/wireless/intel/iwlegacy/3945-mac.c b/drivers/net/wireless/intel/iwlegacy/3945-mac.c index c148654aa9533..e8ae6687c08ec 100644 --- a/drivers/net/wireless/intel/iwlegacy/3945-mac.c +++ b/drivers/net/wireless/intel/iwlegacy/3945-mac.c @@ -979,9 +979,10 @@ il3945_rx_allocate(struct il_priv *il, gfp_t priority) struct page *page; dma_addr_t page_dma; unsigned long flags; - gfp_t gfp_mask = priority; while (1) { + gfp_t gfp_mask = priority; + spin_lock_irqsave(&rxq->lock, flags); if (list_empty(&rxq->rx_used)) { spin_unlock_irqrestore(&rxq->lock, flags); --- base-commit: 0138af2472dfdef0d56fc4697416eaa0ff2589bd change-id: 20260327-iwlegacy-gfp-fix-d553e3340b4f Best regards, -- Brendan Jackman