Received: by 2002:a25:c593:0:0:0:0:0 with SMTP id v141csp304429ybe; Tue, 3 Sep 2019 23:17:26 -0700 (PDT) X-Google-Smtp-Source: APXvYqxJrRCazLeBQz91ummkKrxi5up3RhfTIHX3QMPg/TkfDev5M8dYb7etoRzJAG01KtW/5ttd X-Received: by 2002:a17:90a:630a:: with SMTP id e10mr3219647pjj.25.1567577845925; Tue, 03 Sep 2019 23:17:25 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567577845; cv=none; d=google.com; s=arc-20160816; b=L/qZfJ3KPognYPAdqM0+OEm2ft/Hr0DO3zzACJJbqc9GxwZJX6BIVI8ojeC2SQ4rmD Uv6nxzqG9zSu4BfV1ClvwQQ033rW9rEa3TBwIos8jiA45YGVb3Q1mzu4m0LaQqFzB+Yp 9OocMpwXXNVoT7hsG/CioggfUHzkN8lQIdrlPRcwIw1z7HIgXZKfC/w9AjHjcZ/wUYwo kGbLY7RjUivgUk34MzA8eRHfPbagM3uihgWS2Pr6MrhOYAv+HgA8s2TK9a81BwQMuH3p UlsfKP1H1h9s/I8/wnvTJawQbCtUO0GaNV8CqO60Qa06RKCZD+sSV4OjfQjlklb7tGmp 4vYw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-transfer-encoding:content-disposition:mime-version :references:message-id:subject:cc:to:from:date; bh=yxzAg8IVO5zBs1lxuSneajaHj8bNkiKndEAvgo85qYI=; b=Eo+s2I1ja5eLoThRG2Ue1UFK4dSnR+9jGZarLtEemz51KKLmiYZQtlHMoarYodjVYS TxiWyUkDsJsr/87oqjEk9HvAEsd4lCXd/qL/eLtlvOtTPvaobu5rUKZNBvwYnDXJASh2 /V6cT+yVig64cCAgYcCTFOUH+Rn516SzboWxoGvq8klFzoU/EYpLBgIhZJcaxvuFS+YS iDBt4NHIoQ9jNOWQjbkKoFxH6nyz3QrS3u63kHhrk6Ay6GWw7ASeWnPH8oJKdXYQWIp7 RtpDlj8PMs/CzUAo09wcgTz0/67/09MTYgADq73Hr7aPhJ2zxaMptRh3pDDc+d3vjkxh nlEg== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id v1si15955991plo.118.2019.09.03.23.17.09; Tue, 03 Sep 2019 23:17:25 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728703AbfIDGPE (ORCPT + 99 others); Wed, 4 Sep 2019 02:15:04 -0400 Received: from mx2.suse.de ([195.135.220.15]:33342 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726589AbfIDGPE (ORCPT ); Wed, 4 Sep 2019 02:15:04 -0400 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 8055DACB4; Wed, 4 Sep 2019 06:15:02 +0000 (UTC) Date: Wed, 4 Sep 2019 08:15:01 +0200 From: Michal Hocko To: Qian Cai Cc: Eric Dumazet , davem@davemloft.net, netdev@vger.kernel.org, linux-mm@kvack.org, linux-kernel@vger.kernel.org, Petr Mladek , Sergey Senozhatsky , Steven Rostedt Subject: Re: [PATCH] net/skbuff: silence warnings under memory pressure Message-ID: <20190904061501.GB3838@dhcp22.suse.cz> References: <1567177025-11016-1-git-send-email-cai@lca.pw> <6109dab4-4061-8fee-96ac-320adf94e130@gmail.com> <1567178728.5576.32.camel@lca.pw> <229ebc3b-1c7e-474f-36f9-0fa603b889fb@gmail.com> <20190903132231.GC18939@dhcp22.suse.cz> <1567525342.5576.60.camel@lca.pw> <20190903185305.GA14028@dhcp22.suse.cz> <1567546948.5576.68.camel@lca.pw> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1567546948.5576.68.camel@lca.pw> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Cc printk maintainers On Tue 03-09-19 17:42:28, Qian Cai wrote: > > > 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, > > ? > ?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 > ? > > 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