Cc printk maintainers
On Tue 03-09-19 17:42:28, Qian Cai wrote:
quoted
quoted
I suppose what happens is those skb_build() allocations are from softirq,
and
once one of them failed, it calls printk() which generates more interrupts.
Hence, the infinite loop.
Please elaborate more.
If you look at the original report, the failed allocation dump_stack() is,
<IRQ>
warn_alloc.cold.43+0x8a/0x148
__alloc_pages_nodemask+0x1a5c/0x1bb0
alloc_pages_current+0x9c/0x110
allocate_slab+0x34a/0x11f0
new_slab+0x46/0x70
___slab_alloc+0x604/0x950
__slab_alloc+0x12/0x20
kmem_cache_alloc+0x32a/0x400
__build_skb+0x23/0x60
build_skb+0x1a/0xb0
igb_clean_rx_irq+0xafc/0x1010 [igb]
igb_poll+0x4bb/0xe30 [igb]
net_rx_action+0x244/0x7a0
__do_softirq+0x1a0/0x60a
irq_exit+0xb5/0xd0
do_IRQ+0x81/0x170
common_interrupt+0xf/0xf
</IRQ>
Since it has no __GFP_NOWARN to begin with, it will call,
printk
vprintk_default
vprintk_emit
wake_up_klogd
irq_work_queue
__irq_work_queue_local
arch_irq_work_raise
apic->send_IPI_self(IRQ_WORK_VECTOR)
smp_irq_work_interrupt
exiting_irq
irq_exit
and end up processing pending net_rx_action softirqs again which are plenty due
to connected via ssh etc.
--
Michal Hocko
SUSE Labs